Why wouldn't you want to do this? It's not like it has a high overhead or
anything ...
> I was thinking there would be a place in memory which i could find and
> just access the tick count via memory, is this possible?
AFAIK, it depends on the OS (and possibly the build) that it's running on.
In Windows XP SP1, the value is stored in the address 0x7FFE0000, with a
scaling factor stored in 0x7FFE0004 (ie: 4 bytes later). On my computer, it
is scaled by 15.625 (it's stored as a fixed-point number with 24 bits after
the decimal place). The psuedocode looks something like
TickCount = ((0x7FFE0000) * (0x7FFE0004)) >> 24
Of course, this is probably different between 9x and NT kernels, and
possibly even between NT5 (2k/xp) and NT4. You'd have to disassemble
kernel32.dll on each of them to have a look.
[...]
--
Michael Brown
www.emboss.co.nz : OOS/RSI software and more :)
Add michael@ to emboss.co.nz - My inbox is always open
Right. It's so inaccurate.
Always use timeGetTime() or QueryPerformanceCounter() instead.
========================================================================
(Mr.) IIJIMA Hiromitsu, mailto:delm...@ht.sakura.ne.jp
aka Delmonta http://www.ht.sakura.ne.jp/~delmonta/
No standard and/or documented place. What's wrong with GetTickCount()?
The GetTickCount API consists of exactly 5 instructions. It is silly of
you to avoid it.
The Win32 API *IS* the low-level system access interface. Do not search
for anything lower.
>would it be possible to use another api. it seems that it would either
>have it in memory or have it in a file or registry..
Registry?!?!? What on earth would make you think it was FASTER to read
something from a disk file than to call a system API?
--
- Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
This is a better question for one of the MS newsgroups, although you'll be
hard pressed to get an answer anywhere because this sort of thing is undoc.
They store the tick counter in USER_SHARED_DATA. Disassemble GetTickCount
and you will find it:
kernel32!GetTickCount:
77e7a29b ba0000fe7f mov edx,0x7ffe0000
77e7a2a0 8b02 mov eax,[edx]
77e7a2a2 f76204 mul dword ptr [edx+0x4]
77e7a2a5 0facd018 shrd eax,edx,0x18
77e7a2a9 c3 ret
-Matt
Yeah i figured thats the way to do it..
But i was thinking there would be a more solid address like the bios
clock or w/e i need a good 32-bit asm tutorial or book...
To many examples are in 16-bit and i know the basics well but it's
little things that stop me from coding the whole thing..
Good luck,
Mauricio
"Matt Taylor" <spam...@crayne.org> wrote in message
news:Hq5Sc.27729$wM....@twister.tampabay.rr.com...
Haha its not about speed its about not having to refrence any apis in
a file.
I'm writing a pe encryptor and i use the system time as a randome
seed. from this seed it chooses and encryption method based on a
division of that seed
from there it encrypts and writes the decrypt loader this way reverse
engineers are less likely to be able to code something that
universially unencrypts my programs.. it's a way to slow there
progress and make it harder for them to do anything.. most people know
the api as being used to seed random values so i figured if i read
from memory like the bios clock or could do a int 1ah call without a
fault.. not sure seh handling would fix that problem
i really need a 32bit asm tutorial.. to many i've read are based on
dos and 16-bit and i can do all of that fine and easy. but porting
some of the code causes trouble and i want my encryptor to work
modernly... guess thats a better explanation of why and what i need
Thanks... i found if i read 7ffe0000 and other parts of memory i can
get a random seed which i can multiply and get a full value which
suits my task.. cheers for input
SEH wouldn't, of course. I hope you realize that this will only slow
experienced crackers down by an hour at most.
> i really need a 32bit asm tutorial.. to many i've read are based on
> dos and 16-bit and i can do all of that fine and easy. but porting
> some of the code causes trouble and i want my encryptor to work
> modernly... guess thats a better explanation of why and what i need
Don't rely on DOS/BIOS interrupts and don't use segments. Also, use 32-bit
registers instead of 16-bit registers. That's about it.
-Matt
Cause you can use the RDTSC instruction to somehow get same effects for what
your trying to do.
--
Elias
"Paradox" <spam...@crayne.org> wrote in message
news:e5ffff78.04080...@posting.google.com...
I think you've already had replies about this. Since this
is an ASM newsgroup, I have a lower level possibility:
Why not use the `rdtsc` instruction to read the Time-Stamp
Counter? Scale & offset to ticks if needed.
-- Robert
That "scale & offset" operation is not necessarily trivial, because it
isn't always obvious how to determine cycles per second. That's especially
true on the modern processors that "downshift" at unexpected times.
That won't work on all machines. Some machines change their clock speed.
-Matt