Dear Kernel list,
I want to fake the time returned by the time() system call so that for a
limited number
of user space programs the time can be set to the future or the past
without affecting
other applications and without affecting system time-- Ideally I would
like to install a
loadable module to accomplish this- Any hints ? Any starting points?
Thanks SA
> I want to fake the time returned by the time() system call so that for a
> limited number
> of user space programs the time can be set to the future or the past
> without affecting
> other applications and without affecting system time-- Ideally I would
> like to install a
> loadable module to accomplish this- Any hints ? Any starting points?
The timetravel module that Tigran wrote for Y2K testing should do.
Alan
On Mon, 11 Feb 2002 11:49:39 +0000 SA products <[email protected]> wrote:
Sp> I want to fake the time returned by the time() system call so that for a
Sp> limited number
Sp> of user space programs the time can be set to the future or the past
Sp> without affecting
Sp> other applications and without affecting system time-- Ideally I would
Sp> like to install a
Sp> loadable module to accomplish this- Any hints ? Any starting points?
I am attaching an "ending point", i.e. a complete working module.
Web page will be at http://www.prodata.lt/dateshift/ in a few weeks.
Regards,
Nerijus
SA products wrote:
> Dear Kernel list,
>
> I want to fake the time returned by the time() system call so that for a
> limited number
> of user space programs the time can be set to the future or the past
> without affecting
> other applications and without affecting system time-- Ideally I would
> like to install a
> loadable module to accomplish this- Any hints ? Any starting points?
Maybe could you use a shared library loaded with LD_PRELOAD that
overrides the libc's time() function ?
IMHO this is simpler (and safer) than writing a kernel module, but
it will only work with dynamically linked programs, not with static
nor suid-ed programs.
--
** Gael Le Mignot "Kilobug", Ing3 EPITA - http://kilobug.free.fr **
Home Mail : [email protected] Work Mail : [email protected]
GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959
Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA
"Software is like sex it's better when it's free.", Linus Torvalds
On Mon, Feb 11, 2002 at 11:49:39AM +0000, SA products wrote:
>
> Dear Kernel list,
>
> I want to fake the time returned by the time() system call so that
> for a limited number of user space programs the time can be set to
> the future or the past without affecting other applications and
> without affecting system time-- Ideally I would like to install a
> loadable module to accomplish this- Any hints ? Any starting points?
Here's an LD_PRELOAD shared library that will do the trick... just
export the environment variable FAKETIME with the time that you'd
like, and then export the LD_PRELOAD environment variable to point
that the faketime.so library, and then execute your program. All
programs that have these two environment variables set will have their
time faked out accordingly.
- Ted
On Mon, 11 Feb 2002 11:49:39 +0000, SA products wrote:
>I want to fake the time returned by the time() system call so that for a
>limited number
>of user space programs the time can be set to the future or the past
>without affecting
>other applications and without affecting system time-- Ideally I would
>like to install a
>loadable module to accomplish this- Any hints ? Any starting points?
If you're doing this to defeat a program's security or licensing scheme, let
me warn you that there are many ways this could be detected. Inconsistencies
in different time functions, filesystem times that are way ahead of system
time, times built into networking protocols (and thus received from remote
machines), detection of times before other run time, and so on.
DS
On Mon, Feb 11, 2002 at 11:49:39AM +0000, SA products wrote:
>
> I want to fake the time returned by the time() system call so that for a
> limited number of user space programs [...]
Hi. I'm experimenting with a patch to User Mode Linux which enables
it to do this sort of thing.
Other responses (eg, LD_PRELOAD) here are probably more directly useful
to you, but I thought User Mode Linux bore mentioning anyway, depending
on what you're trying to achieve[1].
<URL:http://user-mode-linux.sourceforge.net/>
-----sharks
[1] Just out of interest, what _are_ you trying to achieve?
On Mon, Feb 11, 2002 at 10:47:23PM -0500, Theodore Tso wrote:
>
> Here's an LD_PRELOAD shared library that will do the trick... just
> export the environment variable FAKETIME with the time that you'd
> like, and then export the LD_PRELOAD environment variable to point
> that the faketime.so library, and then execute your program. All
> programs that have these two environment variables set will have their
> time faked out accordingly.
But note that this doesn't work with programs linked statically. If
you must fool one of those, ptrace() is the only way to do it without
some sort of kernel patch or module I think.
Andreas
--
Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
---------------------------------------------------------
+49 521 1365800 - [email protected] - http://www.devcon.net
On Tue, 12 Feb 2002, Andreas Ferber wrote:
> On Mon, Feb 11, 2002 at 10:47:23PM -0500, Theodore Tso wrote:
> >
> > Here's an LD_PRELOAD shared library that will do the trick... just
> > export the environment variable FAKETIME with the time that you'd
> > like, and then export the LD_PRELOAD environment variable to point
> > that the faketime.so library, and then execute your program. All
> > programs that have these two environment variables set will have their
> > time faked out accordingly.
>
> But note that this doesn't work with programs linked statically. If
> you must fool one of those, ptrace() is the only way to do it without
> some sort of kernel patch or module I think.
luckily, someone wrote such a kernel module - syscalltrack,
http://syscalltrack.sf.net.
it's in alpha stages right now, but it seems pretty stable so far (It
Works For Me - i run it regularly on all of my machines). note that we
currently support only logging system calls (a-la strace) and failing
them with a user given parameter- rewriting system call parameters will
require additional hackery, but not too much of it - on the order of one
day of work. volunteers are welcome.
--
mulix
http://vipe.technion.ac.il/~mulix/
http://syscalltrack.sf.net/
Hi!
> I want to fake the time returned by the time() system call so that for a
> limited number
> of user space programs the time can be set to the future or the past
> without affecting
> other applications and without affecting system time-- Ideally I would
> like to install a
> loadable module to accomplish this- Any hints ? Any starting points?
You can do that in userland, see subterfugue.sf.net.
Pavel
--
(about SSSCA) "I don't say this lightly. However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa
Hi!
> > > Here's an LD_PRELOAD shared library that will do the trick... just
> > > export the environment variable FAKETIME with the time that you'd
> > > like, and then export the LD_PRELOAD environment variable to point
> > > that the faketime.so library, and then execute your program. All
> > > programs that have these two environment variables set will have their
> > > time faked out accordingly.
> >
> > But note that this doesn't work with programs linked statically. If
> > you must fool one of those, ptrace() is the only way to do it without
> > some sort of kernel patch or module I think.
subterfugue.sf.net can do this. It has ready-to-use timeshift/timemultiply
module.
> it's in alpha stages right now, but it seems pretty stable so far (It
> Works For Me - i run it regularly on all of my machines). note that we
> currently support only logging system calls (a-la strace) and failing
> them with a user given parameter- rewriting system call parameters will
> require additional hackery, but not too much of it - on the order of one
> day of work. volunteers are welcome.
Why do you need kernel module at all?
BTW syscall rewriting is pretty hard (subterfugue solves that, but it definitely
took more than a day.
Imagine open('/foo/bar')
you rewrite it to open('/funny/bar')
then another thread comes and rewrites it back to '/foo/bar'.
Or imagine open(address in read-only memory).
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
On Tue, 12 Feb 2002, Pavel Machek wrote:
> > it's in alpha stages right now, but it seems pretty stable so far (It
> > Works For Me - i run it regularly on all of my machines). note that we
> > currently support only logging system calls (a-la strace) and failing
> > them with a user given parameter- rewriting system call parameters will
> > require additional hackery, but not too much of it - on the order of one
> > day of work. volunteers are welcome.
>
> Why do you need kernel module at all?
since we want to trace unknown processes. if you check the home page,
you'll see a few examples of situations in which strace, or any user-land
solution that does not trace the _entire_ system, can't handle properly.
we also want to have a minimal performance penalty - anything using ptrace
has a large performance penalty.
> BTW syscall rewriting is pretty hard (subterfugue solves that, but it definitely
> took more than a day.
>
> Imagineopen('/foo/bar')
>
> you rewrite it to open('/funny/bar')
>
> then another thread comes and rewrites it back to '/foo/bar'.
this is because you think of "rewriting the user process's memory" in
user-space. when the code is in the kernel - this is not the case.
ofcourse, you cannot insert a full python (or perl or whatever)
interpreter in the kernel [or perhaps you can? is this complete
blasphemy? :) ]. we do think of adding some interface to externalize
syscall tracing into user-land to allow people to still have such
features, but most usage we envision for this tool won't require that.
> Or imagine open(address in read-only memory).
again - you're talking about user-space intervention that actually
re-writes the user's data. we just want to invoke the syscall with
modified parameters - or to modify the data the syscall returns to the
user (whic won't stem from these race-conditions or r/o problems, since
the user _wants_ to receive that data).
i suggest that you take a look at the project's page if you wish to see
what we have in mind. personally, i hear of "a tool that already does
this" at least once a month. then i think "oh... why do we bother?". then
i go checking and see that it's not doing what we want, or its not doing
it right (user-land that slows the system and cannot trace the whole
system. or too limited filtering mechanisms. or kernel code that only
exports to user-mode, and thus affects performance. or kernel code that
requires patching a kernel, and thus cannot just be compiled and loaded
into a running machine, etc).
hope it helps,
--
guy
"For world domination - press 1,
or dial 0, and please hold, for the creator." -- nob o. dy