From: nki00 on

> That's great. Not sure if you checked out my latest code but at least
> you have something to choose from.

No, what is the link to it?


> I wanted to use OllyDbg but I realized that when you open "My Computer"
> (or similar) in Windows 7, a new process starts and then closes. Some
> "dllhost.exe". Maybe injects something into explorer.exe (wild guess
> here)? Would have imagined that the process would stick, so I am not sure
> if it's handled by explorer.exe entirely or what. Because of this, I
> realized it wasn't going to be super easy, so I didn't bother thinking
> more about it.
>

Yeah, I looked into this Windows 7 64-bit version I just got and it is quite
difficult to tap into. I was actually more concerned with the Registry and
even there all the data seems to be scrambled (although in some easy manner)
but it is not what it used to be even in XP. Plus, the amounts of memory
available for Windows and the speed with which the code can be executed and
written makes it very difficult to use a debugger on. I'm not sure if most
of that Windows 7 stuff is well documented anyway?


> I also realized that enumClassObj remained unchanged but I saw that they
> used a while loop in an example code on MSDN, so I just did the same.
>
> IEnumWbemClassObject* pEnumerator = NULL;
> ...
> while (pEnumerator)
> ...

This 'while' serves as both an 'if' in case pEnumerator is NULL and an
infinite loop, which is actually a clever design. I didn't catch it
initially, so I should give it to that guy at MS who wrote it :)


> After looking a bit more at their example, it seems like you should call
> enumClassObj->Release() in the end as well which I didn't do.
>

Yeah, I forgot to mention. I caught it too. (I never run someone's code
without rewriting it. :)


From: David Schwartz on
On May 31, 5:06 pm, "nki00" <lukkycha...(a)gmail.com> wrote:

> Yeah, I noticed it. I learned something too. For instance, the following is
> a valid and complilable construct in MS VC++:
>
> a..         while (enumClassObj)
> a..         {
> a..             //....
> a..         }
> a..         while (returned > 0);

It's legal under any compiler. However, if returned is greater than
zero, it will spin forever. The formatting is confusing you. It's
equivalent to:

while (enumClassObj) { /*statements*/ }

while(returned > 0) /*no statement here*/ ;

So the last 'while' repeats nothing at all.

DS
From: Jackie on
On 6/1/2010 04:26, nki00 wrote:
> :) Yeah, I scoured all over the MSDN and the web as well and can't find any
> explanation as to where that memory might be going to. The strange thing is
> that I agree that such can be true with my Dell laptop (and Vista 64) that
> has a crappy video card and probably uses some of the system RAM. But the
> second machine is a desktop with Windows 7 64-bit, and a graphics card with
> dedicated 1GB of its own RAM, so there's clearly no need for that machine to
> use up any of the system RAM.

I meant more like a small part of memory that the OS is using for itself
that can't be used for anything else no matter what.

> (That's pretty much how they sell those new HDD's. Mine has 1.5 TB on the cover and Windows shows
> 1.36 TB.) I have no proof of it though.

HDD space is measured in base 10, meaning kilo is 1000 instead of 1024.
It can cause quite some confusion for people when it's calculated
differently here and there. That's why I say KiB (kibibytes - kilo
binary bytes) like others also are doing, but I am not sure if it is a
standard (it was not at the time I learned about it, I think). So if the
label says 1.5 TB, let's try this:
1.5 / (2^40 / 10^12) = 1.364 TiB

And that's the same number you gave. :)

My laptop HDD is 200 GB. Looking in Windows, it says 186.31 GB.
Let's try this:
186.31 * (2^30 / 10^9) = 200.0488 GB

I wish I was better at debugging. I
> used to do it with SoftICE (while it still existed) but now it's a
> completely different ballgame with a 64-bit architecture.
>

Yeah. I just use OllyDbg now, and a plugin which allows debugging 64-bit
applications. I also have another plugin which changes the disassembler
engine in case I need it. It's only a user-land debugger though. Plugins
are FullDisasm and Olly Advanced.

FullDisasm: http://www.beaengine.org/ - I have useed of some of these
libraries, by the way.
I usually get other plugins from OpenRCE:
http://www.openrce.org/downloads/details/241/Olly_Advanced
From: Jackie on
On 6/1/2010 04:34, nki00 wrote:
> No, what is the link to it?
>

It was in an earlier reply I made.
Just a few changes like in the pow() function (because it was measured
in KiB instead of bytes). The rest was mostly the same changes in
variable names and the WQL query.
http://pastebin.com/hjDYhaKD

> Yeah, I looked into this Windows 7 64-bit version I just got and it is quite
> difficult to tap into. I was actually more concerned with the Registry and
> even there all the data seems to be scrambled (although in some easy manner)
> but it is not what it used to be even in XP. Plus, the amounts of memory
> available for Windows and the speed with which the code can be executed and
> written makes it very difficult to use a debugger on. I'm not sure if most
> of that Windows 7 stuff is well documented anyway?
>

Not sure what you mean with the registry. And if you mean the system
would run slower when you have a kernel debugger running, that's
understandable. You should only use it when needed.
I am only taking a guess here by saying Windows 7's internals probably
would not be documented much in detail, other than general things like
how processes work, security, etc.

> This 'while' serves as both an 'if' in case pEnumerator is NULL and an
> infinite loop, which is actually a clever design. I didn't catch it
> initially, so I should give it to that guy at MS who wrote it :)

Seems logical. I just saw it and used it without looking more into it as
it is not production code anyways.

> Yeah, I forgot to mention. I caught it too. (I never run someone's code
> without rewriting it. :)

All that code for such a small thing looks like pure junk to me so I
would copy/paste and change the important parts to give it a try at
first, then rewrite it later. I saw MS' example after already writing
most of my (non-production) code from scratch.
From: Leo Davidson on
On Jun 1, 12:29 pm, Jackie <Jac...(a)an.on> wrote:

> HDD space is measured in base 10, meaning kilo is 1000 instead of 1024.
> It can cause quite some confusion for people when it's calculated
> differently here and there. That's why I say KiB (kibibytes - kilo
> binary bytes) like others also are doing, but I am not sure if it is a
> standard (it was not at the time I learned about it, I think). So if the

Using "KiB" only resolves half the ambiguity. People still have to use
context and guesswork to understand what someone means when they say
"KB" (unless they've seen the same person use "KiB" somewhere else).

That's why I can't get behind the "KiB" movement. It's advocated by
people who want to reclaim the SI suffixes at any cost; not by people
who want to actually resolve the ambiguity. In fact, the "KiB"
movement is *adding* ambiguity not taking it away. (Until recently, if
you saw "KB" in a user interface, and it wasn't measuring raw disk
size or network throughput, you could be pretty sure it was a multiple
of 1024. Now you can be less sure what it means in any context. The
contexts where "KiB" is actually used were almost all unambiguously
multiples of 1024 when "KB" was used in the past, so that hasn't
helped much either. Not that it wasn't an unfortunate problem
originally, but it's been made worse, not better.)

If the "KiB" movement had also advocated new suffixes for the
multiples of 1000 in computing contexts, with the aim of never using
the ambiguous SI-style suffixes at all when discussing byte sizes,
then I might have joined them.