i am urging members to participate in the forum because there are some rewards when doing it.  rewards like money?  definitely not! becoming popular?  well in a way, yes!  but the true reward is enhancing one's analytical and programming skills.  where can you find a better training ground than foxite forum?  inside the forum, you'll get a lot of cases you have never encountered before, or ideas you never thought of yourself.

one of these is registry hacking using vfp.  in my line of job as an i.t. manager, i always resort to using group policy management this and that or manually modifying contents of registry.  i have the programming skill but it never entered my mind to use vfp in doing so for registry hackings, until last friday when mahmoud inside foxite forum requested ways for an os to ignore usb mass storage that will be plugged into the cpu.  

unbeknown to some, my original suggestion is to go to the device manager and manually disable the usb devices there; which is what i sometimes do over here when implementing restrictions.  after posting, i immediately saw an unwanted side effect which is when you disable the usb devices using device manager, you will be totally disabling it, meaning everything that will be plugged into it will likewise be ignored (cameras, printers, mouse, etc.).  what he wanted is only usb mass storage devices.  so i immediately changed my suggestion to give him exactly what he wants in a form of an exported cleaned registry entry.

later, he asked if it can be done programmatically; and i have never done that yet so it came as another challenge for me to find out how i can do it.  and i resorted to scripting.

it is after posting the scripting solution when i thought "if i was able to do that on usb mass storage detection using vfp by way of scripting, why not use vfp as well with other restrictions?"  and so i begin playing with that idea immediately when i went home.  the first thing that enters my mind is "the invisible data", another way and an easier one!

the invisible data, another way:

if you have read my "the invisible data" article, you will know that the topic is how to hide the records from the prying eyes of users.  if you haven't yet, read it!  that first one though is a little bit complicated because that would require some knowledge on i.t. related stuff but the protection is better on that one.   this new idea, as i have said is selective drive(s) hiding via scripting, run inside a vfp form.

but darn!, i bashed my head this way and that way but i cannot make it work. i even rolled my eyes up trying to look inside my brain and in doing so i became dizzy, and immediately fell asleep, lol!  heck!  if you cannot think of a way that time and it is already sleeping time, sleep it over!  there is no point in making yourself more miserable when you are already exhausted!

early next morning (saturday), i resumed working on figuring out why my hackings do not work the way i intended it to be.  so i work alternating  between modifying the registry manually and using scripting.  deleting the entry and trying it again via scripting and always checking what happens inside the registry, most of the times restarting my unit to see if it works or not.  man that is tiresome!  all still to no avail!

then suddenly, i realized the reason why.  it is just in front of my eyes all the time.  when i am using scripting, i was creating it as a string entry while what is needed is a dword!  so the next problem is how to make it a dword entry using scripting.  and so i continued playing with the newly acquired registry scripting knowledge even placing the words "dword", "dword:" and  "=dword:" to several locations, again all to no avail.  finally, i decided to google it up and i found the hows on msdn. i was finally able to do it before lunch time.  if you will ask me why i haven't googled it up immediately?  it is because that is what i always do, play on it myself first before asking others or googling for solutions.  in that way, i am familiarizing myself more with the commands.

i have attached here a small tool that can do these two things: 

a.  the ability for the os to ignore flash drives and any mass storage device that is plugged onto a usb port; then restore it later.  for the benefit of non-foxite members, here is how:

* value is 3 to enable, 4 to disable usb mass storage detection.  we will disable it in the commands below
local lowsh as wscript.shell
lowsh = createobject("wscript.shell")

simply saying, if you want to enable back the os' capability to recognize usb mass storage devices, just turn the value back to 3.

b.  the ability to hide selective drives or all drives, and to show them back.   

  • map (i believe the most commonly used and simplest approach in multi-tasking applications) a network drive where your data resides

  • using my tool here, click on the mapped drive where your data is, example: drive z:, or some more drives you want to be hidden as well (listbox's multiselect is .t.), then click the hide selected drives button.  hacking is done in a blink of an eye.  i am not kidding, try to blink, it will be actually faster than your blinking, lol!.  it will ask you immediately if you want to restart the local unit (after blinking your eyes).  this is needed as tampering with registry entries requires a log off or better a restart for it to be implemented.

i always forgot to mention this, but on all of my blogs, articles and tutorials, i am only testing those under winxp 32-bit.  so if this will  work on other os, i don't know.  still, xp is a good way of testing things plus i doubt that with registry, things change that much.

i believe that this idea will benefit more developers than my first idea of an invisible data considering majority of developers resort to drive mapping than unc path.  however, the first idea can protect your app better than this one.  still, this is a ready made tool so all you need to do is download what i decided to give here and your mapped drive can now become invisible.   if a user of your app is just an ordinary one, he will not be able to find where the data reside.  so he cannot tamper with it intentionally or unintentionally!

in my side comment, i said that "if tweakui can do it, why can't we using vfp?"; i mean it.  here is what i have come up so far yesterday out of the tool attachment i gave here (that attachment is done the other day, the image below is the enhancement of that tool and is done yesterday)!   most of these though are for i.t. personnels.

one more time, enjoy!


per request of my friend, doc ammar haddi, and for the benefit of interested readers, i am now showing my codes on hiding/revealing of drives:

init event of the listbox

local lnloop
* create all letters for the drive
create cursor junkdrive (xdrive c(1))
for lnloop = 65 to 90
    insert into junkdrive values (chr(lnloop))
this.rowsource = "junkdrive"
this.rowsourcetype = 6

click event of the command button

local lowsh as wscript.shell, lcregkey1, lcregkey2, lnoldval, lndrives
dimension ladriveval(90)
lnoldval = 1
lcregkey1 =[hkey_current_user\software\microsoft\windows\currentversion\policies\explorer\nodrives]
lcregkey2 =[hkey_local_machine\software\microsoft\windows\currentversion\policies\explorer\nodrives]
lowsh = createobject("wscript.shell")
lndrives = 0
do case
case this.parent.optiongroup1.value = 1
    local lnloop
    for lnloop = 1 to this.parent.list1.listcount
        ladriveval(m.lnloop) = iif(m.lnloop=1,m.lnoldval, m.lnoldval * 2)
        lnoldval = ladriveval(m.lnloop)
        if this.parent.list1.selected(lnloop) = .t.
            lndrives = m.lndrives + m.ladriveval(m.lnloop)
case this.parent.optiongroup1.value = 2
case this.parent.optiongroup1.value = 3

note:  actually i already modified my sample attachment into the image above so if there will be slight problem with the above codes, it will be change of location from a form's object into a container one.


i am not advising playing with registry.  if you don't know what you are doing, please do not try it as it may result to unwanted problems.  the original reason why i gave this tool as an exe is because i am pretty sure it will work without problem on your side (using xp 32-bit).  still, i am withholding any responsibility on whatever will happen on your end.  play at your own risk!

3 Responses to Registry Hackings

Leave a Reply

Your email address will not be published. Required fields are marked *