Have you considered using ssh command's ProxyCommand option? It allows you to replace the TCP transport with communication over stdin/stdout.
It could help you replace the TUN with something more cross platform, and possibly with less overhead. You can pass in the hostname using %h, so you can even have virtual DNS.
That's what I've been doing since I was 12 years old :)
My first "programming" experience was with mIRC scripts. I even wrote an IRC client using mIRC sockets at some point, and a dummy webserver / SMTP client. When you do things the wrong way, you pick up a lot of new skills. I learned to "reverse engineer" (my implementations were trivial, not fully fledged) protocols with a proxy/sniffer pretty early :)
From there, the first use case I had for every new language I wanted to learn was write an IRC bot. I had written one in VB6, VB.NET, Python and even C/C++ at some point.
It's funny to see this comment on HN, as this has been my mantra for a while now. On top of string manipulation and networking, another important piece it teaches you about a language is using data structures and manipulating data.
IRC client is super stateful. For example, it needs to maintain the list of channels you're in, the list of users in those channels, their op/voice status, etc.
Highly recommended as a project for picking up a new language.
Me too! I will never forget adding "runtime loadable moduels" to my PHP IRC bot at age ca. 14. Oh my was that functionality a travesty: a user might say something like `!load poll` to activate the poll module. What would my code do? Oh it'd `include poll.php` (or whatever the syntax is, this was both my first and my last PHP project) in the main loop. On every iteration. Because hey, how else would the poll code be able to react to stuff?
I learned a lot of lessons and still have fond memories 20 years later :-)
Edit: Man, just thinking at this has Metallica playing as background music in my head even though I haven't listened to them in this decade. It's so strange how childhood memories can be so incredibly strong and cover so many sensory modalities. These days I can hardly remember what I did last week.
> My first "programming" experience was with mIRC scripts. I even wrote an IRC client using mIRC sockets at some point, and a dummy webserver / SMTP client.
Same here! The mIRC scripting language was incredibly rich, and the ability to create native Windows dialogs with it was a powerful tool.
Back in the 90s, a friend and I reverse engineered the protocol behind a popular program used to play Magic the Gathering online called Apprentice. The protocol was insecure and allowed users to cheat by controlling the outcome of coin flips and other elements of the game. The purpose of the research was to prove definitively that the client could be manipulated, in order to resolve some cheating accusations that had been thrown around.
I set out to write a program that would hook into Apprentice through the Win32 API and allow you to change the program's output, while my friend created an mIRC man-in-the-middle server that you could configure through a dialog box to connect to Apprentice and modify incoming and outgoing protocol messages.
My project never shipped and his reached widespread availability, eventually leading to the development of better clients [1]. The fact that he was able to get so much out of mIRC script (dialog boxes, sockets, event handling, etc) and was able to make it simple for others to use was impressive.
What’s written on the SIM card is called ICCID.
For some carriers, you can convert from IMSI to ICCID and vice versa, because they chose this convention.
I don’t write client side browser code these days any more, but when I did back in the 2000s, I remember people bashing using tables for layout, and how everyone should switch to CSS.
From quick googling of what CSS Grid Layout is, seems to be like we’re back to using tables, we just offload it to the style sheet.
I've mostly been a frontend dev since the late 1990s. CSS Grid does feel like building with tables in some respects. You don't suffer the problems tables had though, like the close coupling of layout to HTML, the necessity to have a tag for every cell, the rigid order of cells, or the spacer gifs to stop things collapsing. CSS Grid gives you the formality of a proper grid system with some really nice features for spacing, placement and ordering the content. Plus, in Grid, cells can overlap with other cells, so it's fairly easy to make some really clever designs that look great. It's been very well thought out, and it works.
I really wouldn't want to go back to even plain Flexbox now, let alone floating elements, tables, or any other layout system.
The tables bashing was because of the common view that CSS and HTML, the styling and markup, should be separated. It wasn't due to tag bloat, which has remained common with HTML regardless (we still have a million div tags in the place of table/td/tr).
<table> is a rigid display value taking up an entire tag. So the argument is why not push that into the CSS eg in a div instead and get rid of an entire unnecessary tag. This is why display:table doesn't get the same kind of hate thrown at it that <table> does.
“Tag soup” doesn’t mean “bad markup”. It specifically refers to when you write HTML as a series of commands and the result is a bunch of tags that aren’t nested properly and don’t result in a tree structure. Things like <b><i>…</b></i>.
So they should’ve added new tags for layout, instead of table,tr,td,th ?
Much like yield vs await in Python3 asyncio.
In the Python 2.7 days, people used generator functions to implement async in Python. When Python3 first came out, you couldn’t do both generator and async in the same function. I assume it’s because they used the same mechanism internally.
I think it was Python 3.5 which added support for async generators.
I don't believe python 2.7 could ever do async. Async was only possible in 3.3 when `yield from` landed and then was bastardized into coroutines through decorators.
3.5 released true asnyc/await based on the `yield from` form and then 3.6 allowed for async generators.
You were close and your point remains. Although I don't think new tags are the right choice. I think HTML learnt a while ago that more tags doesn't solve everything.
I do really enjoy python async. It's cool to see a feature develop from a hack like that but a language first approach could have avoided some headaches. This is where Grid wins, it's a fresh take without requiring to maintain backwards compatibility with previous attempts.
I think the philosophical difference is meant to be that in HTML tables the layout was part of the markup (and so had -- or should have had -- semantic meaning) whereas with CSS Grid the table layout is part of the styling. This is alluded to in TFA's section on accessibility.
For devs who don't care so much about accessibility, and are more just interested in getting the layout they want, I guess that argument may not resonate so much. I personally don't care much for taxonomic/teleological arguments around REST methods, but I'm a bit more willing to follow fashion with Grid if it means people on screen-readers will have a better time.
How about make the login process more resource intensive on the browser side, by running some intensive javascript code before sending it to the server?
The trick would be to make this much more intensive on the client side (say 1s of CPU time), while keeping this relatively easy for the server (say 1ms). We're trying to waste their resources, not ours.
One way I can think of:
1. server sends a random seed to the client
2. client calculates 1000 hashes based an random numbers generated from the seed, something like hash(rand() + password) and sends them to the server
3. server picks a one of those and validates it. In case the hash isn't valid, you'll respond with an invalid password, so the client won't be able to distinguish between a failed authentication because of hash validation or because of a wrong password.
That's doable but you have to process a lot of traffic from the clients because the client would have to send all the answers it has calculated.
Do exactly what bitcoin does: You send a random prefix and require the client to find a random suffix so that hash(prefix+suffix) ends with, say 4 zeros.
So. Someone is wasting your time, so you want to start wasting everyone's time and natural resources playing games with a script?
Stay away from trying to increase computational overhead. Everyone thinks computation is "free", but it isn't. There is a turbine somewhere cranking out annoyed pixies to drive your computation war with this botnet. The fact some actor has decided to distribute the energy cost to someone else doesn't mean you have to double down on the waste by multiplying the botnet operator's energy expenditure being dealt with by oblivious user's a thousandfold.
It's a bit like global thermonuclear warfare. The only winning mover is not to play.
The least resource intensive way of dealing with it is just detection and either preemptive drop (no more useful info) or if you want to get creative, start doing some whois digging with IP's and start blowing up some operator's inboxes with questions as to why you are getting malicious login traffic from their IP block so they can start running down the source from their end.
This is the Internet. We don't know everything going through it, but most operator's are generally open to trying to keep transits clean if they are made aware of a problem in a way that doesn't seem like a DDoS aimed at their time.
If you manage to do it for only suspicious-looking login attempts, thats actually a great way to both stall them and benefit. it just feels so much win
but are these scripts sophisticated enough to run JS etc?
If you fail to detect a bad botnet once and show the mining script to an important crawler (like a search engine), and then land on a blacklist, it could potentially require a huge effort to get off it again. It's simply not worth the risk.
Some of them can run Javascript, I'm thinking specifically of people who write scrapers in things like PhantomJS (headless browser, very very cool software).
I want to second this. The things I wrote throughout my career that I'm most proud of aren't very complex.
I find it very satisfying to understand a problem so well, up to the point you can find a simple and elegant solution to it. It makes the solution easier to reason about with other team members, and easier for the team to maintain it later.
I see this as making your domain expertise available as a framework for the other team members.
This is my idea of sophistication in the software development world.
Simplicity is always a sign of a quality solution. I’m not sure why anybody would ever conflate complexity with quality or sophistication. I wrote some very complex code in college, but it wasn’t very high quality.
To date, my most complex piece of software in terms of how it was implemented was a simple calculator written in my first programming course. About a week before I started it, I had learned about regular expressions (the programming construct, not the formal language construct).
The basic implementation was a calculator that could add, sub, mul, div, pow, and sqrt. Bonus points were awarded for adding additional functionality including lettered variables. It started with a relatively clean shunting-yard implementation, but my use of regular expressions quickly fixed that.
My calculator worked under most circumstances, but that thing is an eye sore. I'll never get rid of that source code. I like to go back and look a few key pieces of software I've written through the years.
I think devising this plan altogether was a huge investment in time and patience. Consider the social engineering feats needed to get your hands on the driver signature cerificates, for example. And that's just one step in the entire sequence of lateral movement.
Apple should allow to do this in Software.
Make the lockdown mentioned in the link happen immediately when USB is disconnected, forcing you to retype the PIN every time.
Could be a cool feature for the privacy concerned crowd.
Unless I'm mistaken, this is the way that Android already works. If you plug in a locked phone, you must unlock it to get any USB data connection to the phone. When a phone with a data connection is unplugged, the permissions immediately reset and you have to unlock the phone again to restart a data connection.
Not only that, on my Nexus 5x, I have to manually switch from charging mode to data transfer mode every time (the setting doesn't stick).
Unless I've misunderstood the significance of this change, Android actually provides much more security since you can't download files off a locked phone, not even within 7 days.
Yes, the iPhone is the same. You get a ‘Trust this computer?’ prompt which forces you to unlock the phone first.
The trouble is, this is still a data path that has been opened via USB. This new change disables the data path altogether and just allows charging via the USB power pins only - like its a USB battery or USB fan, simply power and nothing else. Which is pretty neat.
Because then you can’t plug in the device and have it sync automatically. It’s a security/convenience trade off.
By the way they don’t use the same pins as USB of course because they have their own connectors. And disabling access to the audio dongle while the device is locked wouldn’t make sense.
It could help you replace the TUN with something more cross platform, and possibly with less overhead. You can pass in the hostname using %h, so you can even have virtual DNS.