Cortana Tutorial - Armitage
Cortana Tutorial - Armitage
Cortana Tutorial - Armitage
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
stores binary data in a string. So long as you do not use character processing functions, the<br />
content of the string will not change.<br />
It is the scripter's responsibility to make local resources available on a remote server<br />
before Metasploit references them. If Metasploit is running locally, these functions will<br />
continue to work as expected.<br />
Locking<br />
Sometimes it is desirable for a script to signal to other scripts that they should not perform<br />
an action or touch a resource for a time. <strong>Armitage</strong> and <strong>Cortana</strong> do this implicity with shell<br />
sessions. If your script sends a command to a shell sesssion, <strong>Cortana</strong> queues the command,<br />
and attempts to gain a lock for the shell before executing your script's commands.<br />
It's possible to create your own locks using the &lock function. One place this is used in<br />
<strong>Cortana</strong> is the &host_import function. This function uses the db_import console command<br />
to import a file. If two scripts try to import a file at the same time, one or both imports will<br />
fail. It's important to prevent this if possible. Here's how it's done:<br />
sub host_import {<br />
lock("db_import_lock_internal", 1, $1);<br />
}<br />
The &host_import function requests a lock for db_import_lock_internal. The second<br />
parameter indicates that the lock should not be freed automatically after the locked_*<br />
event handlers finish, rather the script would prefer to release the lock when it's ready.<br />
This is safe to do by the way. If a client disconnects from the team server, all of its locks are<br />
automatically freed.<br />
Additional parameters to the lock function are stored and passed to the locked event when<br />
it fires. The argument passing to the lock is important. It's possible that a script may want<br />
to request a lock several times with different variations on each call. The argument passing<br />
allows that script to differentiate between requests and service the right one.<br />
Here's the locked event for our db_import_lock_internal lock:<br />
on locked_db_import_lock_internal {<br />
when('console_db_import', lambda({<br />
fire_event_local("db_import", $hostf);<br />
unlock("db_import_lock_internal");<br />
}, $hostf => $1));<br />
cmd_async("db_import \" $+ $1 $+ \"");<br />
}<br />
The locked_db_import_lock_internal event is fired when our script gains the requested<br />
lock. The first thing our listener does is register a one-‐time listener for the db_import<br />
console command to complete. It then asynchronously executes the db_import command<br />
with the argument passed by the &lock function.<br />
Once the import completes, our one-‐time listener fires and releases the lock.<br />
23