Hiya folks,

I've finished writing a new essay about our beloved debugger (SI heh), that gives some insight on some of the useful commands it has (some advanced, some not).
If any1 is interested in checking it out, it should be posted at the ID site pretty soon.

http://www.immortaldescendants.org/

Cyas!

LS

Thank You m'lord,
Generosity with knowledge is a path to Nirvana.
May life be Kind with your Honor.

I look forward to all new essays! Thank you.

Regards,
Zee.

Went there, got that. Good stuff. Thank you kindly.

Regards, Kugi

i cant connect to the site

also it was previously on tsehp's page, but now it's removed?

hmm,

Weird, I don't know why it has been removed. Go figure..

LS

Too non-threatening, too non-target-specific, too generic maybe? No animals or shareware authors were harmed in its making, heh.

Nice tut BTW, I especially liked the heads up on the DEX command, that removes one of my major aggravations. I know it's in TFM, but I never thought to use it!

I just read a quote tonight that I think applies to a lot of what goes on in here:

Employ your time in improving yourself by other men's writings so that you shall come easily by what others have labored hard for.

--Socrates


Ciao,
Kayaker

I wonder if anyone has problems with the SICE macro's.
if i define them in my Winice.dat and restart my puter the macro doesnt get loaded and sice doesnt recognize the macros i defined..

1. since the original site/url seems to be down, try this:

http://mirror1.immortaldescendants.org/

2. on 'watch'



this is not correct, a BP (on memory access i assume) lets you catch code that
attempts to access (read/write) memory, whereas a watch does not. on the
other hand, a watch makes it easy to keep an eye on expressions (which can
be memory content) whenever softice is active (visible) and it updates the watch
window. in other words, they're different animals, used for different purposes.



this is not true, the total number of BPs is 256 (hardcoded limit in softice).

3. on 'addr'



the CPU has no knowledge of 'processes' and their 'address spaces', rather it's
the OS that creates these abstractions using the features of the CPU. on IA-32
CPUs it means making use of the paging logic (for which protected mode must be
enabled).

i'm not sure what you meant by 'there "should" be no trespassing', if you mean
that separate address spaces have been conceived in order to protect user
applications from trashing each others' memory, then it's correct, but then i don't
understand your saying 'We have come to learn though, that in Windows9x, this is
far from the truth'. do you mean that user processes are able to access each
other's address space in a controlled manner (ie. with OS kernel assistance, in
win32 OSs that would be read/writeprocessmemory)? but then you can state the
same for many other OSs as well, NT, Linux, BSDs, etc.



some clarification here. in win9x the 'context' of a win32 process covers the linear
address range of 0x00400000-0x7FFFFFFF, as you pointed that out earlier in your
essay. however when a context switch occurs, VMM!_ContextSwitch updates the
Page Directory Entry for the range 0-0x003FFFFF as well. this specific PDE
happens to be common for all contexts because contexts are created for win32
processes only which in turn get created in the System VM (ie. when the current
VM is the System VM).

damn, it didn't post the first reply, so here it is, simplified:

Hi btw :-)

About the watch issue, I never meant for it
to sound as if it was a memory access BP.
I know it well not to be a BP, but something
else. I'll need to rephrase my essay.

As for the 16 BP limit, I remember I've read
it in a SI guide sometime, altho I can't
remember. I'll check it out and update that
too.

As for the trespassing. What I meant was that
it is only too easy for a process to access
another process' address space by accident,
and otherwise. This has several reasons,
which I'm sure you are aware of. Whether it's
the global memory sharing above 2Gb, and the
16 bit code areas (mainly the kernel, user
and gdi modules), which have to also be
global to all due to them being 16 bit (yup,
relates to the win16mutex problem), and of
course lets not forget security, which is
totally ignored in win9x. So a process can
read any other process memory with a function.
In NT it's different. Many functions use a
security attributed structure and security
is enforced so it's harder to poke in other's
memory.

thank you for your comments, i'll go update

LS

PS. the board says my nick is taken (probly because I've registered using it), but
shouldn't it let me login ??

I have a few questions concerning this;
(For those that know more than me don't laugh
at my sillyness
Your post seems to be a bit mixed up, can you
please clarify:

1. What do you mean by the Win16Mutex Problem ? Mutex
(Mutual Exclusion) is something that is AFAIK used for sync issues.

2. I don't think a Win9x process can write to another process'
address space erroneously via a bad ptr or something similar.
As you guys mentioned before, all of what normally be user-mode
memory is being remapped, so the only thing a process could do
is corrupt stuff that would be in protected kernel memory under
any "real" OS.

LordSoth, can you please clarify ?

Hello,

Well, I can try and clarify. Yet The Owl knows more than me on this issues, so
I'll bet he'll have something to add as well.
The best way to learn about the win16mutex is in matt pietriek's windows
programming secrets. That book is highly recommended, the guy did an awesome
job reversing many internal mechanism in windows.
In short, when MS set out to design win95, they wanted to make an OS that
will be new, and yet will be able to be backwards compatible with win3.11 16bit
programs. One other important design consideration was that they (apparently)
didn't want to rewrite all the windows internals code. For obvious reasons, that
code was much more stable than a newly coded system from the ground up.
So what they decided to do is to somehow build upon the win3.11 16bit libraries
with some more 32bit libraries. In fact, most of the real work of the OS is done
in those old 16bit libraries, which are also apparently, are not entirely 16bit, but
rather a hybrid. In any case, for the reasons mentioned earlier, 16bit memory
cannot be protected like 32bit code using hardware, and maybe some of those
libraries use functions that are non-reentrant (which sounds all too acceptable,
but I'm not certain on this point). In that case there would be a synchronization
problem in the OS when multiple threads execute the same lines of code in the
16bit libraries. It's basically like you can't use a function that uses a static
variable of any kind, if you expect multiple threads to run through it's code at
the same time (which can happen, since a thread has among other things it's
own register set, stack pointer, stack, etc..). MS decided to solve this sync
problem using a mutex. They called that object the Win16Mutex. Each thread
that would have to enter 16bit code will have to acquire control of the mutex
before continuing, and if a different thread is currently executing in 16bit code,
it has the win16mutex acquired so the other thread is put to sleep.That way MS
solved the sync problem with the 16bit libraries, which of course hampered
win95's multithreading. Apparently, as pietriek noted, it is possible to do some
weird things while you obtain the mutex, and in general, since 16bit code has
to be global to all processes, and many important things like window handles
and gdi object handles are stored in those libraries data segments, a process
can do great harm to the system.
I hope that clarified that a little.
You mentioned a process can't access memory outside of it's space with a
weird pointer. Well, that is true in general, but is not a 100% sure thing.
Since the 32bit libraries are also mapped globally, a badly pointed pointer (sorta
speak hehe) can do harm to the system. In fact, it's all too easy to cause
harm to the system or other processes if you try. On top of that there are
the XXXXprocessmemory functions (read and write), which give you a great
deal of power in your hands, since all processes in win9x are created equal,
and there are no security limitations

If you survived this long typing endeavor, i salute you my friend ;-)

ciao,
LS

In a truly multithreaded OS non-reentrant functions are not acceptable or at least not ideal for obvious reasons.

Thanks for explaining me what a mutex something.
Thanks for explaining me that a thread has its own register set.
I didn't ask for that either, but its good to tell the newbies on this
board about it.

The clarification I asked for is the relationship between the
Win16Mutex and your statement that the 16-bit code is mapped gobally
and can thus be corrupted by an errant pointer.



It has been a while since I saw an errant pointer constructing
all arguments to a certain API call on the stack and then overwriting
some pointer to get execution into the *ProcessMemory functions.
And even when I saw this, this was hardly by accident.

While the security subset of the Win32 API is not supported or
enforced in win9x AFAIK (correct me if I am wrong, I know nothing
about 9x internals)

Anyways, in case *ProcessMemory functions succeed, there obviously
*should* be "trespassing" as these are features (not bugs) supplied
by the OS.

Without wanting to restart the flamewar that apparently lead to
banning of people on this board, I would kindly suggest that you try
to limit the amount of information you're posting with each sentence.
You're trying to cram a lot of what is called "dangerous half-truths"
into your essays; Please try to be more to the point.
Something I usually do when I write something is to write it, then to
let it rest for a week, and then to slowly re-read it; That way you get
a distance to your work that enables you to see how unclearly and
unready the first vresion was. Correct everything then, and repeat
until you feel your stuff is concise, to the point, true, and under-
standable.

Cheers,
Halvar

/me pokes lord_soth (;

hehe

PS.
HalVar, thank you for your comments. I think I just might do what you suggested, it sure sounds like a good idea.

LS