Jump to content


 


Register a free account to unlock additional features at BleepingComputer.com
Welcome to BleepingComputer, a free community where people like yourself come together to discuss and learn how to use their computers. Using the site is easy and fun. As a guest, you can browse and view the various discussions in the forums, but can not create a new topic or reply to an existing one unless you are logged in. Other benefits of registering an account are subscribing to topics and forums, creating a blog, and having no ads shown anywhere on the site.


Click here to Register a free account now! or read our Welcome Guide to learn how to use this site.

Photo

Anyone know how to disable system32 being transformed into SysWow64 when using RegSetValueExW?


  • Please log in to reply
14 replies to this topic

#1 Grinler

Grinler

    Lawrence Abrams


  • Admin
  • 43,659 posts
  • ONLINE
  •  
  • Gender:Male
  • Location:USA
  • Local time:07:54 PM

Posted 07 March 2012 - 12:51 AM

I am trying to add a reg_expand_sz value to the registry using the RegSetValueExW. My code works, but I run into a problem when I am using a 32-bit app on a 64-bit machine. Instead of the %SystemRoot%\system32\asdasd.exe being added to the key, the Registry Redirector or File Redirector changes my reg_expand_sz and adds it as %SystemRoot%\syswow64\asdasd.exe instead.

This is not what I want and thus is a problem.

Anyone know of a way around this other than using a 64-bit program on a 64-bit OS? I would like to be able to use 32-bit programs regardless of the version of Windows so I dont have to have two different executables.

Come help the site owner and get some brownie points :)

BC AdBot (Login to Remove)

 


#2 Billy O'Neal

Billy O'Neal

    Visual C++ STL Maintainer


  • Malware Response Team
  • 12,304 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:Redmond, Washington
  • Local time:05:54 PM

Posted 07 March 2012 - 01:05 AM

You need to check if your program is running under WOW64, and if so, pass the value KEY_WOW64_64KEY value as part of the samDesired parameter when calling RegCreateKeyEx.

For more information, see Registry Key Security and Access Rights, specifically, the values KEY_WOW64_64KEY and KEY_WOW64_32KEY. You may also be interested in the specifics of the Registry Redirector.

*EDIT*: FYI, this isn't really specific to MSVC++; any other application calling the Windows API will have the same caveats (e.g. ICC or MinGW).

Edited by Billy O'Neal, 07 March 2012 - 01:09 AM.

Twitter - My statements do not establish the official position of Microsoft Corporation, and are my own personal opinion. (But you already knew that, right?)
Posted Image

#3 Grinler

Grinler

    Lawrence Abrams

  • Topic Starter

  • Admin
  • 43,659 posts
  • ONLINE
  •  
  • Gender:Male
  • Location:USA
  • Local time:07:54 PM

Posted 07 March 2012 - 08:14 AM

Yes, I have read those articles and am already using those flags. Still does not help.

KEY_WOW64_64KEY only disables reg_sz/reg_expand_sz substitution in Windows 7 and newer. For older versions of Windows, it will have no effect on string substitution.

Edited by Grinler, 07 March 2012 - 08:28 AM.


#4 Billy O'Neal

Billy O'Neal

    Visual C++ STL Maintainer


  • Malware Response Team
  • 12,304 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:Redmond, Washington
  • Local time:05:54 PM

Posted 07 March 2012 - 08:55 AM

Ah, I see; you appear to be correct. In that case your only option is to build a native x64 binary, or get a native x64 binary to do your dirty work for you. (The local x64 copies of regedit or reg.exe should work...)

Billy3
Twitter - My statements do not establish the official position of Microsoft Corporation, and are my own personal opinion. (But you already knew that, right?)
Posted Image

#5 Grinler

Grinler

    Lawrence Abrams

  • Topic Starter

  • Admin
  • 43,659 posts
  • ONLINE
  •  
  • Gender:Male
  • Location:USA
  • Local time:07:54 PM

Posted 07 March 2012 - 09:24 AM

Would having a 32-bit executable that extracts and uses a 64 bit dll or driver be able to solve this issue?

#6 Billy O'Neal

Billy O'Neal

    Visual C++ STL Maintainer


  • Malware Response Team
  • 12,304 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:Redmond, Washington
  • Local time:05:54 PM

Posted 07 March 2012 - 10:24 AM

Driver might work: DLL will certainly not. (you would have to way to load the DLL into your process)

Billy3
Twitter - My statements do not establish the official position of Microsoft Corporation, and are my own personal opinion. (But you already knew that, right?)
Posted Image

#7 Andrew

Andrew

    Bleepin' Night Watchman


  • Moderator
  • 8,260 posts
  • OFFLINE
  •  
  • Gender:Not Telling
  • Location:Right behind you
  • Local time:04:54 PM

Posted 07 March 2012 - 01:36 PM

Wouldn't calling RegDisableReflectionKey work here?

#8 Billy O'Neal

Billy O'Neal

    Visual C++ STL Maintainer


  • Malware Response Team
  • 12,304 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:Redmond, Washington
  • Local time:05:54 PM

Posted 07 March 2012 - 01:54 PM

No Andrew, that disables registry reflection, not the implicit renaming of data. See Registry Reflection for more details.

Billy3
Twitter - My statements do not establish the official position of Microsoft Corporation, and are my own personal opinion. (But you already knew that, right?)
Posted Image

#9 Andrew

Andrew

    Bleepin' Night Watchman


  • Moderator
  • 8,260 posts
  • OFFLINE
  •  
  • Gender:Not Telling
  • Location:Right behind you
  • Local time:04:54 PM

Posted 07 March 2012 - 03:30 PM

/me shuts up and learns a thing or two. :)

#10 Didier Stevens

Didier Stevens

  • BC Advisor
  • 2,734 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:01:54 AM

Posted 07 March 2012 - 06:14 PM

I would like to be able to use 32-bit programs regardless of the version of Windows so I dont have to have two different executables.


You could do what Mark Russinovich does with many of his Sysinternal tools: he releases 32-bit versions of his tools with a 64-bit .exe embedded.
When you start the 32-bit .exe on a x64 machine, it extracts the 64-bit .exe in the same folder and runs that.
And after you're done, it deletes it.

Example: run Process Explorer on a x64 machine. You'll see procexp.exe (32-bit) and child process procexp64.exe (64-bit).

Didier Stevens
http://blog.DidierStevens.com
http://DidierStevensLabs.com

SANS ISC Senior Handler
Microsoft MVP 2011-2016 Consumer Security, Windows Insider MVP 2016-2019
MVP_Horizontal_BlueOnly.png

 

If you send me messages, per Bleeping Computer's Forum policy, I will not engage in a conversation, but try to answer your question in the relevant forum post. If you don't want this, don't send me messages.

 

Stevens' law: "As an online security discussion grows longer, the probability of a reference to BadUSB approaches 1.0"


#11 Billy O'Neal

Billy O'Neal

    Visual C++ STL Maintainer


  • Malware Response Team
  • 12,304 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:Redmond, Washington
  • Local time:05:54 PM

Posted 07 March 2012 - 06:28 PM

You could do what Mark Russinovich does with many of his Sysinternal tools: he releases 32-bit versions of his tools with a 64-bit .exe embedded.
When you start the 32-bit .exe on a x64 machine, it extracts the 64-bit .exe in the same folder and runs that.
And after you're done, it deletes it.

This has a couple of undesirable side effects. First, you're writing to the filesystem, which has safety implications (e.g. what do you do if the name you've chosen to extract to already exists? Blow it away?), as well as "mess" implications (e.g. your app crashes, now there's a strange x64 binary lying around). Now, for Sysinternals tools specifically, they already had this downside, because most of these tools use a driver and thus already need this kind of "extract and fool around" craziness.

Moreover, your app then doubles in size unnecessarily; if I know I have only x64 machines, why force me to pay in terms of transfer costs to download the 32 bit copy?

This is a workable solution, yes. But not one that I'd recommend; I'd personally rather see separate apps; if the user tries to run the 32 bit app on 64 bit Windows, you can insert a check asking him or her to download the 64 bit version instead; and if you try to run the x64 version on 32 bit Windows, (at least recent) versions of Windows will generate an error message to the same effect asking the user to go back and get the x86 version.

Billy3
Twitter - My statements do not establish the official position of Microsoft Corporation, and are my own personal opinion. (But you already knew that, right?)
Posted Image

#12 Grinler

Grinler

    Lawrence Abrams

  • Topic Starter

  • Admin
  • 43,659 posts
  • ONLINE
  •  
  • Gender:Male
  • Location:USA
  • Local time:07:54 PM

Posted 07 March 2012 - 10:53 PM

You could do what Mark Russinovich does with many of his Sysinternal tools: he releases 32-bit versions of his tools with a 64-bit .exe embedded.
When you start the 32-bit .exe on a x64 machine, it extracts the 64-bit .exe in the same folder and runs that.
And after you're done, it deletes it.

Example: run Process Explorer on a x64 machine. You'll see procexp.exe (32-bit) and child process procexp64.exe (64-bit).


Yup, that is what I planned on doing. Actually have it working already and was surprised with how easy it was to setup once I figured out how to properly extract the resource. Luckily, I found some code that put me on the right path.

Billy makes some good points below.

This has a couple of undesirable side effects. First, you're writing to the filesystem, which has safety implications (e.g. what do you do if the name you've chosen to extract to already exists? Blow it away?),


I already have something in place to make a random filename in the event that the file I want to write exists. In that event that this random file exists, it will recreate another one and check for its existence again, etc etc until the file does not exist. I think this should more than satisfy the potential of overwriting an existing program.

as well as "mess" implications (e.g. your app crashes, now there's a strange x64 binary lying around). Now, for Sysinternals tools specifically, they already had this downside, because most of these tools use a driver and thus already need this kind of "extract and fool around" craziness.


Agreed. If the main 32 bit app crashes, the 64 bit app will stick around. If the 64 bit app crashes, the 32 bit app will still clean it up. I am willing to take that chance for the reason I will give below.

Moreover, your app then doubles in size unnecessarily; if I know I have only x64 machines, why force me to pay in terms of transfer costs to download the 32 bit copy?


Once again, I agree with this, but doing it this way would only increase it by 400k. In today's high bandwidth, an extra 400k is not going to hurt many people.

So we have the true cons that cannot be overcome:

1. Possible crash and leftover 64 bit app.
2. Extra 400KB download.


Now the benefits of doing it as a 32 bit app with an embedded exe are far greater IMHO:

Simply put, ease of use. The people who will be using this app may not have enough computer knowledge to determine their computer's bit type and download the appropriate program. For those of us who have a high level of computer expertise, it is very easy to overlook this simple truth. Therefore, for my needs which is to have a program for my guides that I don't have to rely on the user, who may be badly infected and struggling enough, to then have to figure out the version of the program they need. By encapsulating the 64-bit version in the 32-bit version, I can now offer one download in the guides that will work in ALL cases. That is immensely beneficial.

For those who want to use the tool and are more knowledgeable, I will also offer the 64 bit version for download that they can use instead. So in reality its only the 32bit people who are going to have the potential cons. Right now 32-bit computers have 61% market share on the virus removal that goes on at BC. I guarantee this will go down in time and 64-bit will start taking the lead as all new computers these days are sold with 64-bit versions of windows installed.

#13 Billy O'Neal

Billy O'Neal

    Visual C++ STL Maintainer


  • Malware Response Team
  • 12,304 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:Redmond, Washington
  • Local time:05:54 PM

Posted 07 March 2012 - 11:01 PM

The people who will be using this app may not have enough computer knowledge to determine their computer's bit type and download the appropriate program.

It does not matter if they know the bitness of their machine. If they download the wrong one, the app tells them to download the other one. Sure, they might download the wrong one from time to time, but putting them both together effectively has them *always* download the wrong one.

Yes, 400k on broadband is squat... but if I recall correctly we have a sizable percentage of people who are still on dial-up, do we not? (Not positive myself there)

Billy3
Twitter - My statements do not establish the official position of Microsoft Corporation, and are my own personal opinion. (But you already knew that, right?)
Posted Image

#14 Grinler

Grinler

    Lawrence Abrams

  • Topic Starter

  • Admin
  • 43,659 posts
  • ONLINE
  •  
  • Gender:Male
  • Location:USA
  • Local time:07:54 PM

Posted 08 March 2012 - 09:47 AM

but putting them both together effectively has them *always* download the wrong one.


Or it effectively has them *always* download the right one as well. Sometimes the best approach technically is not always the best approach in terms of usability.

Yes, 400k on broadband is squat... but if I recall correctly we have a sizable percentage of people who are still on dial-up, do we not? (Not positive myself there)


Unfortunately I have no way of determining this.

#15 Animal

Animal

    Bleepin' Animinion


  • Site Admin
  • 35,905 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:Where You Least Expect Me To Be
  • Local time:04:54 PM

Posted 09 March 2012 - 11:19 PM

According to an ars technica article By Nate Anderson June 19, 2009 it says that US broadband penetration is/was at 60%. I'm sure that it may be slightly higher today. If our membership is any reflection of US broadband use we should at the very least be 50%+ broadband enabled members.

Article: US 20th in broadband penetration, trails S. Korea, Estonia

The Internet is so big, so powerful and pointless that for some people it is a complete substitute for life.
Andrew Brown (1938-1994)


A learning experience is one of those things that say, "You know that thing you just did? Don't do that." Douglas Adams (1952-2001)


"Imagination is more important than knowledge. Knowledge is limited. Imagination circles the world." Albert Einstein (1879-1955)


Follow BleepingComputer on: Facebook | Twitter | Google+




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users