I want to create a custom powershell module that I can distribute without exposing the code. The script includes API calls with app specific private keys that I don't want to compromise. I've seen a lot of discussions about this over the years, but nothing that really solves my problem.
Is there a good way to create a custom powershell module without exposing the underlying code? I want to be able to distribute the powershell module, for others to import or install.
this may be what you are looking for : https://www.powershellgallery.com/packages/ps2exe/1.0.11
but be careful, the API key will still be in the compiled file at someplace. You can try and cipher it, but if it's needed for your script, it will be in your file no matter how you try to hide it. the question is why do you need to ship it inside your script in the first place ? I mean that any of your script's user will be using your private key which is likely not what you want to do
Related
I'm working with a Lenovo Thinkpad and I'm trying to set the asset tag in Powershell without using Lenovo's WinAIA.exe utility due to restrictions at work (wouldn't be able to access Windows. We would be running everything before we got into Windows Setup via Powershell), and I'm not sure how to go about this. Essentially, the property "SMBIOSAssetTag" (from the WMI class win32_SystemEnclosure) is ReadOnly, and I cannot get around this. I did triple check to make sure that Lenovo does not have its own namespace, and while using the Powershell Module "LenovoBIOS" I didn't see anything that could help me achieve this goal (unless I'm blind and totally missed it). Is there any way to go about this? I've also tried modifying the ReadOnly property of the SMBIOSAssetTag property, but I couldn't get that to work. I'd love any and all feedback. If there is any extra information needed, I'd be happy to help as well.
You don't. The property is defined as read-only in the MOF spec by design.
You're talking about writing to the SMBIOS information, which is an operation specific to your motherboard's OEM. It's up to your OEM to determine the data structure and storage method of the SMBIOS information, and the SMBIOS standard does not provide a standard write method the same way that there is a standard read method.
I'm working on a library that lets users run Node processes from inside another application. The library is called "max-api"; functions for sending data to the host application are exposed through a Node module and are loaded in the expected way:
const maxAPI = require("max-api");
However, the user never interacts with this module directly. Rather, when the host application launches the Node process, it intercepts the call to require, checks if the name of the module is "max-api", and provides the module if so.
This works great, the only issue is we have no way to provide type definitions for this modules. So, the user doesn't get any autocomplete or validation for functions in the "max-api" module. I was thinking of writing a VSCode extension to provide these, but I'm not 100% sure how to get started. Thanks in advance for any advice.
You could write a TS typings file (see Definitely Typed). This would be installed in node_modules/#types and vscode will automatically pick it up to provide code completion for your module.
I am currently writing a Powershell module that I can use to control some smart light bulbs. A requirement for the API is that I provide an authorization token with each request. I currently have a cmdlet Set-AuthorizationToken that sets a $Script: scoped variable to store this token.
Currently all of the setting functionality I have created exists in the same light automation module. I would like to separate the settings logic into its own module so it can be reused.
This is where I run into trouble. To my knowledge, if I pull the settings logic into its own module then I would no longer be able to use the $Script: scope as that would be shared with any module that consumes the settings module. Additionally I would have to refactor the current settings functionality to some provide some sort of identifier so the settings module can look up the correct settings for the caller.
Is there some way that I can create the settings module so I can reuse it, but maybe load it in a manner that allows it to only know about the module that loads it? Maybe like a "library" of some sort? I would prefer not to copy the ps1 files into each module but currently that seems like the best way.
The typical way to handle this seems to be to store your credentials as an encrypted string in a file and then have a function for loading those credentials.
For example: https://github.com/RamblingCookieMonster/PSSlack/blob/master/PSSlack/Public/Get-PSSlackConfig.ps1
Here's a little code I'm working on: http://pastebin.com/92Nzc6pG
I basically inject code into a running process, but the problem is, that CRT library is no longer valid, so I can't use strings for example. Is there any workarounds for that? Rest of my program requires creating/modifying strings as well, so I really need to get this sorted out.
I managed to get it working with passing a char pointer, like this: http://pastebin.com/T1qdjfRK
However using strings is still kind of a "must" for me, so any workarounds, ideas and whatsoever are welcome.
An easier way to do this would be to inject minimal code that just loads a DLL with proper imports and relocations. All of your imports are going to be satisfied by the loader once the DLL is loaded.
If you really must inject code and not a DLL for some reason, you'd have to make sure your code is compiled against the same CRT the process was compiled against. If it doesn't use CRT at all, you can use static CRT, or not use CRT at all. Windows has built-in string functions like lstrlen() and friends.
By far the simplest method is injecting an entire DLL and not just code. It will be a bit more complicated because it's two steps, but once you're fully loaded, you can do pretty much everything the same way you would have done it in your own process.
I'm very new to Perl, and I have absolutely no idea how to approach this. We have an old Perl application which previously used Apache auth; we'd like to replace this with a cookie based form-style authentication. I understand that this is very case-specific, and there is no one answer as such, but some general tips would be much appreciated.
Will I need to edit all .pl files in the website? Or is there a "golden hammer" solution I can use? Is there something on CPAN I can use? We're using Perl v5.8.8 if it matters, and we're using Apache 2 shared hosting. I am happy to provide additional information as is necessary.
For the authentication to be recognized/required, it will need to be checked by the .pl file that initially receives the user's request. So the answer to whether all .pl files will need to be changed depends on how your application is structured:
If the user goes to http://myserver.com/one.pl to do the first thing and http://myserver.com/two.pl to do the second thing, then, yes, you'll need to change them all because they're all receiving requests individually.
If the user goes to http://myserver.com/dispatch.pl?mode=one for the first thing and http://myserver.com/dispatch.pl?mode=two for the second thing and dispatch.pl calls either one.pl or two.pl behind the scenes based on the mode parameter, then you only need to change dispatch.pl, since it's the only one directly receiving requests from the user.
Edited to add: If you're dealing with the first model, then I'd strongly recommend setting up an external module (.pm file) with the cookie-handling code and calling that from each of your individual .pl files instead of duplicating that code all over the place. Ideally, this would let you get by with only a few lines of added code in each .pl:
use MyCookieHandlingModule qw(verify_cookie redirect_to_login);
my $q = CGI->new; # ...unless you're already using CGI in object-oriented mode
redirect_to_login unless verify_cookie($q);
You could do it at a level outside the Perl program.
Thanks for your answers guys, but I eventually decided on CGI::Session::Auth::DBI which works well on shared hosting.