Any custom metasploit module I create isn't getting loaded.
I tried both of these demos:
https://www.offensive-security.com/metasploit-unleashed/building-module/ https://github.com/rapid7/metasploit-framework/wiki/Loading-External-Modules
and got the same result that the modules were NOT found.
Before posting here, I checked these out:
https://forums.kali.org/showthread.php?28940-Metasploit-modules-not-loading!
https://www.offensive-security.com/metasploit-unleashed/modules-and-locations
and from SO:
I can't get new modules to load in metasploit
How to add module in Metasploit?
no help
Just working with the github example, on the Kali host, I do indeed have the file in the right location (according to the demo):
root#kali:~/.msf4/modules/exploits/test# ls -al
total 12
drwxr-xr-x 2 root root 4096 Mar 19 13:59 .
drwxr-xr-x 3 root root 4096 Mar 19 13:58 ..
-rw-r--r-- 1 root root 9 Mar 19 13:59 test_module.rb
I then ran reload_all and when using this command:
use exploit/test/test_module it returns with Failed to load module.
I also tried to manually load that path and it failed too:
msf > loadpath ~/.msf4/modules/
Loaded 0 modules:
Posting the answer for anyone who may come across this. I'm kinda new to this; didn't know where metasploit info gets logged.
It's in: ~/.msf4/logs/framework.log
The log told me I had a syntax error... must have happened from copying and pasting the text from the browser. Cleaned that up and everything works.
Related
I start off by deleting Gradle's build cache
$ rm -rf $GRADLE_HOME/caches/build-cache-*
I manually confirm this directory is gone. I also clean to ensure nothing from incremental build will interfere
$ ./gradlew clean
I then run a build w/ build-cache enabled:
$ ./gradlew --build-cache --scan app:assembleDebug
...
238 actionable tasks: 172 executed, 49 from cache, 17 up-to-date
Checking the generated report I see that some tasks are still marked as FROM-CACHE. How is this happening?
FWIW I'm using Gradle 5.6.3. I also don't use a remote build cache.
UPDATE: after clearing build cache, here's what's left in the cache dir:
$ pwd
/Users/jasonatwood/.gradle/caches
$ ls -al
total 24
drwx------ 11 jasonatwood staff 352 Dec 13 18:11 .
drwxr-xr-x 9 jasonatwood staff 288 Oct 15 17:24 ..
drwxr-xr-x 14 jasonatwood staff 448 Oct 29 16:07 5.4.1
drwxr-xr-x 15 jasonatwood staff 480 Nov 26 18:25 5.6.3
drwxr-xr-x 35 jasonatwood staff 1120 Dec 11 14:14 jars-3
drwxr-xr-x 5 jasonatwood staff 160 Oct 15 17:44 journal-1
drwxr-xr-x 7 jasonatwood staff 224 Oct 15 17:50 modules-2
drwxr-xr-x 5 jasonatwood staff 160 Oct 15 17:50 transforms-2
-rw-r--r-- 1 jasonatwood staff 39 Oct 15 17:27 transforms-2.lock
-rw------- 1 jasonatwood staff 28 Oct 22 16:34 user-id.txt
-rw-r--r-- 1 jasonatwood staff 17 Dec 13 18:00 user-id.txt.lock
If I understand correctly, I don't need to delete any of these.
The local task cache in the .gradle directory within the root project might interfere.
In order to disable the local/global caching altogether, use gradle.properties:
org.gradle.caching=false
If you remove the local build cache and don't use a remove cache, Gradle should indeed not be able to fetch anything cached on the next build. However, I don't think you actually removed anything.
The GRADLE_HOME environment variable, if you have it, should points to an unpacked local Gradle distribution. It could be something like /Users/jasonatwood/gradle-6.0-all. It would be wrong to set it to a path that is not a Gradle distribution.
The Gradle build cache resides in /Users/jasonatwood/.gradle/caches/build-cache-1.
When you try to remove it with $ rm -rf $GRADLE_HOME/caches/build-cache-*, you are using GRADLE_HOME as if it is pointing to the root of your home folder (/Users/jasonatwood), which it most likely isn't.
So instead, use this for removing it: $ rm -rf ~/.gradle/caches/build-cache-*
Or, at the very least, verify that the cache folder has indeed been removed.
If I run a --scan and look at the FROM-CACHE tasks in the generated HTML report.
I then look at the build cache keys for those FROM-CACHE tasks. I then go find those keys on my local machine. I see they are generated at the same time as the rest of the build. So I'm guessing that Gradle is using build cache within a build and not just across builds.
Sometimes there is a need to invalidate cache every time you restart the IDEA. This may be due to shared indexes reuse. What I did Settings --> Tools --> Shared Indexes -> Download Automatically and it resolved all the pain.
Earlier the setting was Don't download use Local.
I am using mac and I am trying to change my open file limit by modifying the following directory:
/Library/LaunchDaemons
when I created two files I got the following permissions:
-rw-r--r--# 1 root wheel 535 Jul 2 16:36 limit.maxfiles.plist
-rw-r--r--# 1 samu wheel 586 Jul 2 16:53 limit.maxproc.plist
however when I run limit.maxproc.plist file I get the following error:
/Library/LaunchDaemons/limit.maxproc.plist: Path had bad ownership/permissions
which is due to the permissions of my group.
I want to change the group from samu to root but not sure how?
I found the solution. To change a specific file owner to root you can use the following command :
sudo chown root limit.maxproc.plist
I have been following this guide from the gentto wiki to install Gentoo. I have hit a bit of a roadblock though which looks reasonably simple but I am having trouble figuring it out.
On this page: https://wiki.gentoo.org/wiki/Sakaki%27s_EFI_Install_Guide/Configuring_Secure_Boot#test_secure_boot
In the Testing Secure Boot with a Signed Kernel section whilst executing the buildkernel command I get the following error:
* Updating old config using make olddefconfig
make: *** No rule to make target 'olddefconfig'. Stop.
* buildkernel: Error: Caught signal - exiting
I don't seem to have an olddefconfig at all and even if I did have one I am not entirely sure what rule should be added to the make file.
I have read the man page for the buildkernel command and gone over this description here but sadly I have still not managed to fix the issue.
Does anyone know how to rectify this error?
So I now have an answer for this. It sometimes happens when the kernel sources have been updated to a new version, but the symbolic link /usr/src/linux hasn't been updated to
match. Gentoo leaves a partially populated kernel source tree in
/usr/src/linux--genoo even when an old kernel source version is
unmerged, and if the symbolic link /usr/src/linux still points to this.
if you run:
eselect kernel list
and it produces something like:
Available kernel symlink targets:
[1] linux-4.14.63-gentoo-r1
and
ls -l /usr/src/
produces something along the lines of:
total 8
lrwxrwxrwx 1 root root 20 Aug 18 00:33 linux -> linux-4.14.61-gentoo
drwxr-xr-x 23 root root 4096 Aug 18 02:38 linux-4.14.61-gentoo
drwxr-xr-x 25 root root 4096 Aug 18 02:33 linux-4.14.63-gentoo-r1
Running the following command will update the symbolic link and let you get on with things.
eselect kernel set 1
I emailed the author of the guide to get this information so credit goes to her. I am leaving this here in case anyone else runs into this problem in future.
I have recently upgraded my Ubuntu from 14.04 to 16.04 and started getting the following error when running any mvn commands (version 3.3.9): Error: Could not find or load main class .usr.share.maven.boot.plexus-classworlds-2.x.jar. My environment variables are declared as follows:
$JAVA_HOME: /usr/lib/jvm/java-8-oracle
$PATH: /usr/local/texlive/2015/bin/x86_64-linux:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
$M2_HOME: /usr/share/maven
$M2: /usr/share/maven/bin
When trying to find a solution, I've tried removing the M2 and M2_HOME variables as suggested on various threads, which resulted in getting a different error: Error: Could not find or load main class org.codehaus.plexus.classworlds.launcher.Launcher. I have also tried running apt-get remove --purge maven and installing it again as well as downloading the .tar.gz archive, but in both cases, nothing has changed.
When looking into the /usr/share/maven/boot folder, there is a chain of symlinks pointing from plexus-classworlds-2.x.jar -> /usr/share/java/plexus-classworlds2-2.5.2.jar. Am I missing some dependencies? Or are there any old configuration files that did not get removed by --purge?
EDIT: When I execute mvn as root, I get the Launcher error instead of plexus-classworlds-2.x. Also, I have completely removed and reinstalled all plexus libraries, yet with no change.
Check if /usr/share/maven/boot has multiple jars with pattern /usr/share/maven/boot/plexus-classworlds-*.jar.
Mine was something like:
drwxr-xr-x 2 root root 4096 Dec 23 14:21 ./
drwxr-xr-x 6 root root 4096 Nov 14 2015 ../
-rw-r--r-- 1 root root 52684 Dec 12 2015 plexus-classworlds-2.5.2.jar
lrwxrwxrwx 1 root root 34 Dec 10 2015 plexus-classworlds-2.x.jar -> ../../java/plexus-classworlds2.jar
This messes up /usr/share/maven/bin/mvn bash script and executes a wrong java command.
I had to remove the jar and leave only the symbolic link.
"The application has exited during startup (i.e. during the evaluation of config/environment.rb). The error message may have been written to the web server's log file. Please check the web server's log file (i.e. not the (Rails) application's log file) to find out why the application exited."
I'm getting the above error message when I try to access my test site.
Permission for config/* is
-rw-r--r-- 1 www-data root 2011 Aug 27 20:17 environment.rb
drwxr-xr-x 3 root root 4096 Aug 27 20:17 environments
drwxr-xr-x 3 root root 4096 Aug 27 20:17 initializers
drwxr-xr-x 3 root root 4096 Aug 27 20:17 locales
-rw-r--r-- 1 root root 2431 Aug 27 20:17 routes.rb
I've tried "root root 2011 Aug 27 20:17 environment.rb" as well but no success either.
I'm running Debian GNU/Linux and have other Rails sites running fine on the same server, I have tried to replicate the setup from one of the other sites, but it's not having any effect.
I encountered this same issue, and after killing passenger and apache ended up finding:
http://geminstallthat.wordpress.com/2009/03/01/passenger-with-rails-23-application-missingsourcefile/
Essentially the issue is for some versions of libapache2-mod-passenger the app/controllers/application.rb change to app/controllers/application_controller.rb (in Rails 2.3) explodes things (technical term).