FBSL - How to use machine code to get your CPU name

[Gerome]

Hello,

FBSL and machine code are not incompatible...
You can use the FBSL online compiler to see the results : http://gedd123.free..../studio/fbsl2exe.php

[Select]

#Option Explicit

'// The last one is 0 to null-terminate
Dim $CPUName    : Alloc( CPUName, 13 )

'// Set up machine code
Dim MachineCode = Data(&H55,&H8B,&HEC,&H57,&H52,&H51,&H53,&H8B,&H45,&H8,&HF,_
                  &HA2,&H8B,&H7D,&HC,&H89,&H1F,&H8B,&H7D,&H10,&H89,&HF,&H8B,_
                  &H7D,&H14,&H89,&H17,&H58,&H59,&H5A,&H55,&HC9,&HC2,&H10,&H0_
                  )

'// Calls the machine code
CallAbsolute( MachineCode, 0, @CPUName, @CPUName+8, @CPUName+4)
MsgBox(0, CpuName, "You CPU is...", 0)

[f0dder]

Eek, that looks like how pascal did machine code before the inline assembler was added

[Gerome]

Hello,

Eek, that looks like how pascal did machine code before the inline assembler was added

-f0dder (March 18, 2006, 12:25 PM)

The way Fbsl handles 'asm' is in fact a pure trick available via a system APi call, but it works from win95 up to 2003 and even latests M$ actual betas...

[f0dder]

Oh, system call API?

btw, how does your 'asm' code do API calls?

[Carol Haynes]

Looks remarkably like what you used to have to do with a Sinclair ZX81 back in the early 70s

Anyone else remember peeking and poking bytes in memory?

[Gerome]

Hi,

Looks remarkably like what you used to have to do with a Sinclair ZX81 back in the early 70s

Anyone else remember peeking and poking bytes in memory?

-Carol Haynes (March 18, 2006, 06:21 PM)

Peek and Poke exist in FBSL also, but they have been enhanced

Peek( [@ ]addr[+offset], [$%!#]numofbytes )

Parameters
[@ ]addr[+offset] : address from where to retrieve value(s). @ and offset are extended options
[$%!#]numofbytes : you have to precise the very number of bytes to retrieve from the addr variable, and you have to precise the very type by prefixing the very offset by $, %, ! or #

------------------------------------

Poke( [@ ]addr[+offset], [$%!#]val )

Parameters
[@ ]addr[+offset] : variable [address] where to write value(s).
[$%!#]val : value(s) to write to at mandated address. You have to precise the very type by prefixing the very offset by $, %, ! or #

So ?

[Carol Haynes]

Ahhhhhhh - a nostaligia rush has just swept over me .... peek-a-boo ? (I won't try the other version in case of misunderstanding )

[Gerome]

Dear Carol,

Ahhhhhhh - a nostaligia rush has just swept over me .... peek-a-boo ? (I won't try the other version in case of misunderstanding )

-Carol Haynes (March 19, 2006, 05:10 AM)

There are 2 main reasons why we've put Peek and Poke to Fbsl :
- 1st reason is that Peek and Poke are part of the common 'basic' languages since a long
- 2nd reason is that we have found a way of extending it that any peek poke amateur will find more than a great interest

[mouser]

i agree with gerome, for historical reasons every basic should have peek and poke commands.
i wonder if vb.net has them.. if not, boycott it!

[Carol Haynes]

i agree with gerome, for historical reasons every basic should have peek and poke commands.
i wonder if vb.net has them.. if not, boycott it!

-mouser (March 20, 2006, 03:02 AM)

You know it hasn't ... not exactly surprising though as the model used for Visual Studio is pretty much an abstraction to remove direct hardware access.

I haven't use Visual C++, presumably it has malloc() and pointers etc. Does it actually address memory or does it just give that impression? If it does then there really isn't a reason not to include peek and poke in VB.

[mouser]

well c++ support very low level stuff, so you better believe you can access raw memory with c and c++, otherwise it just wouldnt't be c/c++ at all

but it's very understandable that the .net languages would do everything they can to keep you from poking into arbitrary memory since it defeats the whole safety framework.  but now i'm really bringing us off topic..

[Carol Haynes]

I presume even Visual C++ doesn't allow arbitrary rummaging around in all memory - I presume it is restricted to it's own allocation of memory? Presumably VB.Net could allow peeking and poking into its own private memory (esp. on Win2K/XP) without the potential to nuke the entire system?

Can't help feeling security would be an issue though if you can generate code on the fly and then execute it!

[f0dder]

Carol, you need to make a distinction between "Visual C++" and ".net" - VC++, even the 2005 version, can still do unmanaged (native) as well as managed (.net) code.

Dunno how managed code and pointers mix, but they're sure are available for native code. Not that memory allocation with malloc/free and new/delete is a good thing anyway, everybody should use resource management objects for greater security against leaks etc.

Can't help feeling security would be an issue though if you can generate code on the fly and then execute it!

Not a problem, that code will still be limited by NT's security model...

[Carol Haynes]

Carol, you need to make a distinction between "Visual C++" and ".net" - VC++, even the 2005 version, can still do unmanaged (native) as well as managed (.net) code.

-f0dder (March 21, 2006, 08:19 AM)

I was under the impression (probably wrong) that applications in Windows 2k/XP work within allocated virtual memory and can't directly address the hardware memory. I thought if you tried to access memory outside the address range of the apps allocation you got Access Violation errors etc.? Don't all apps have to address Windows and other apps memory via the various Windows libraries/API etc.?? Or am I totally barking up the wrong tree and C++ will let you do what you like?

[Gerome]

Hello,

Carol, you need to make a distinction between "Visual C++" and ".net" - VC++, even the 2005 version, can still do unmanaged (native) as well as managed (.net) code.

-f0dder (March 21, 2006, 08:19 AM)

I was under the impression (probably wrong) that applications in Windows 2k/XP work within allocated virtual memory and can't directly address the hardware memory. I thought if you tried to access memory outside the address range of the apps allocation you got Access Violation errors etc.? Don't all apps have to address Windows and other apps memory via the various Windows libraries/API etc.?? Or am I totally barking up the wrong tree and C++ will let you do what you like?

-Carol Haynes (March 21, 2006, 11:25 AM)

Surely you can't directly with C/C++ do sucha explosive actions.
Under a certain memory scale, you can't access to it via C/C++ and the Kernel prevents you from trying to peek/poke at it : it is normal
But if you are using PSDK and DDK, you can find LIBS that allows you to develop drivers that allows you to have a lower memory access

[f0dder]

I was under the impression (probably wrong) that applications in Windows 2k/XP work within allocated virtual memory and can't directly address the hardware memory. I thought if you tried to access memory outside the address range of the apps allocation you got Access Violation errors etc.? Don't all apps have to address Windows and other apps memory via the various Windows libraries/API etc.?? Or am I totally barking up the wrong tree and C++ will let you do what you like?

Unless you write device driver code (which can be done in C/C++), you're always going to be dealing with virtual memory. Hell, you're dealing with "virtual" memory even in device drivers, unless you *specifially* need a physical memory address (mapping device memory, DMA transfers, etc).

In order to run priveleged device driver code, you need the proper administrative access privileges. So again, this isn't a security problem.

Application level peek and poke will only let you write inside your own program's address space, not even in the address spaces of other programs. Well, it *is* possible to write into another process' memory, but again that requires the necessary privileges.

It's an unfortunate fact that Microsoft decided to make the default users of WinXP have administrative privileges, and this is why windows systems are "insecure". It seems like this is a thing they might be fixing with vista, but hooray and everything, there'll still be millions of XP boxes around for years, and many of those probably will remain unpatched for quite a wihle.