I left my full time job about 3 months ago to start my own software consulting venture. Ive maintained projects from old clients I had on the side, and also created and launched a new project for a client (RN mobile app). Still have to get an online presence setup for the company. Its been going well so far, and I am looking forward to new projects and clients in 2018.
I launched ScrumGenius (https://scrumgenius.com). Its a side project I started for fun at my previous job (it was just a simple slack bot script back then) and decided to actually build a service and launch it a few months ago. I did not take it too seriously at first, I was just using it to learn. However, after reading indiehackers and other people launching products I was really inspired to give it a try. Its been steadily growing and it makes around $300/mo.
Hoping to continue to grow it even more in 2018.
If anyone is looking for a end to end consultant that does Full Stack Dev with experience in mobile and web! Please do reach out, would love to talk! I am based in Canada and UK.
SEEKING WORK - Fullstack Web Developer - Go, ReactJS, AngularJS, Django, Python
location: Toronto, ON
Experienced fullstack Python/Django developer. I have worked on applications large and small. I have modernised legacy applications. I have experience leading a team and delivering results on time.
The hole in Schneier's story is that you can't just send them any old letter. It has to be a card that you've purchased from them.
It's not much of a revelation: "If I actively purchase a token to have something inoffensive sent to an address, why, the company will send it without verifying that the person who handed over the money is the recipient!".
It's not about getting them delivered for free. It's about targeted anonymous harassment (or a prank, depending on your point of view). See also https://shipyourenemiesglitter.com/ or http://poopsenders.com/ neither of which are free.
I fail to see a significant difference between purchasing an ant farm and using the card to anonymously send the sealed tube of ants to a victim... and just anonymously posting something yourself to the victim.
The difference is that if you're anonymously mailing ants to a person you're doing it out of malice. The bad person is the person directly responsible for sending the ants out.
The company doesn't want to mail ants to the wrong people, but they have no safeguards against it either. They're not acting out of malice, but they're peforming a malign action anyway. They're relying on your good spirit to ensure the ants end up in the right place.
There is no difference to the victim if the company sends the ants directly, or if you receive the ants and then re-post it.
This is one of those ridiculous scenarios that security folks dream up. I imagine Schneier doesn't live in a concrete bunker with a blast door, because a regular door can conceivably be broken open with a sledgehammer. The vast majority of homes do not have a sledgehammer-proof door, because it's not actually a problem. Same with the shipping of ants.
There is no difference to the victim, but there is a difference to the company. In one case they are guilty of shipping live ants to an unsuspecting victim, and in the other case they're not even related to the incident.
It would be possible to send packets to the elevator, but the elevator playing them would be another issue. If there is no authentication at all (as it it just plays all packets it receives on UDP 2046) I would imagine you would get an interesting mix of "valid" elevator music and your own "invalid" music.
On the other hand, those first 8 bytes of the packet may be some authentication/verification scheme which would have to be reverse engineered. Also, it may only play UDP packets coming from 234.0.0.2:2046, which would likely mean you would have to convince the DHCP server to assign you that address instead of its intended host.
Wasn't there an article a while back by a guy who stayed at a "smart" hotel and discovered he could turn the lights on and off in other people's rooms? If that's any indication of how this industry is treating security, I say "play some Skynyrd."
> Also, it may only play UDP packets coming from 234.0.0.2:2046, which would likely mean you would have to convince the DHCP server to assign you that address instead of its intended host.
This does not agree with my understanding.
234.0.0.2 is probably the destination address. I think if a DHCP server gave out an address in this range it would be misconfigured.
In 802.3 and 802.11 I think multicast packets are actually broadcast, so this is why you don't need to join the group.
This is not how multicast traffic works. Yes, 234.0.0.2:2046 is apparently the destination. The receivers probably just listen for this destination address and plays whatever it receives. DHCP server wouldn't matter here.
These multicast packets also aren't L2 broadcast addresses. For more info, see:
Group membership matters in multicast, although I agree probably not in this case. If there's a hub-spoke topology and you a spoofing on a leaf switch which doesn't propagate this could be a fun problem for engineering (looking up and reading about IGMP is left as an exercise for the reader)
Well, it doesn't appear that IP spoofing has been setup too well on the switches, because the switch seems to be doing what either an el cheapo switch will do, or do what Cisco switches do which is take the multicast traffic and flood it out the vlan broadcast domain.
Hell, if that's UDP traffic it doesn't necessarily even look like it requires a response, so you could spoof the source IP address and the server might not even care...
yeah and deliver some badass mixes of The girl from Ipanema. :-)
Though I wonder if he had time to look at the packets long or careful enough. Would have been interesting to inspect all these devices closer too. Were there also other sessions established maybe that could hint at controlling them? E.g. such as volume of the sound? I doubt that the actual elevator would be controlled could be controlled remotely:
> those first 8 bytes of the packet may be some authentication/verification scheme
The server could verify the auth on a per packet basis and only play the sound if it matches. There's no reason you couldn't have an authentication scheme on top of a UDP transport, you just can't rely on the tcp sequence numbering to prevent bad actors from injecting into the stream. But so what, you could implement your own thing. You could go so far as to simulate TCP over UDP if you really wanted to.
It's kind of weird for you to address him/her in the condescending tone, especially when you're not exactly correct.
You seem like someone who would be well served by a perusal of the below wikipedia page. Briefly, these packets are destined for an IP address in the 224.0.0.0/4 IP space, meaning multicast. SRC address is neither important nor verified (and since it's UDP on the same broadcast domain, there's really very little that can be done to stop the packets being processed unless the hotel has a very smart access point. They never do).
> *
It would be possible to send packets to the elevator, but the elevator playing them would be another issue. If there is no authentication at all (as it it just plays all packets it receives on UDP 2046) I would imagine you would get an interesting mix of "valid" elevator music and your own "invalid" music.*
At that point (assuming it's the kind of elevator music that uses low-intensity instrumental versions of pop hits), it would be really fun to get the original versions of the songs they're playing and sync up the position and playback rate.
That would definitely be another interesting read! I'm not a networking guy, but I definitely want to know if it is possible to stop the packets from going to their final IP? Can they be intercepted and replaced with other data?
This feels as exciting as what they do with video feeds in Hollywood movies, i.e. where the hacker puts in her own camera loops replacing live feed.
Probably difficult to intercept the packets, but since they're apparently broadcast over the whole hotel network, it would likely be straightforward to send your own out to be mixed in with the real packets and get some sick elevator glitch muzak going.
With custom equipment I bet you could listen for the packet header and broadcast a colliding signal every time a legitimate one was being sent. Since it's UDP, there would be no retry and neither the sender nor the receiver would be the wiser.
Not necessarily, the speakers could be in a different network, then they do not listen to what he sends directly. if the AP/router knows the multicast source is not in the wifi (and it probably does) it won't accept packets from there and not forward it to other networks.
Since it is multicast seeing the packet doesn't mean the path to a specific receiver goes through your network.
There was another recent post about a hotel that had android devices controlling the lights, in the entire hotel. Which had no auth protection at all. I'd bet money, it would be the same for the elevator music.
This would be the obvious follow up, then you can make your own "elevator music" and send it out. But that probably depends on understanding what's in the first 8 bytes too :-)
Just python. I'm by no means an ML expert, this was my first foray into it. I used some basic stats to identify correlated exercises, and then simple linear regression to fit the data to a line. In my mind, linear regression is sufficient for such a simple ML problem.
Our engineering department functions like an independent startup, with financial backing from an established company with a healthy bottom line.
We're looking for someone to help with front end development - notably, visualization of data generated from our back end and big data team.
Experience with Angular, D3 and REST is an asset, but your eagerness and ability to learn trumps all!
You should consider yourself a full stack engineer, despite focusing on front end, as our dev culture strives to have everyone learn a bit of everything.
DETAILS
We are hiring full stack engineers (DevOps experience is greatly valued)
About Us
The parent company is a telecom provider with offices and subsidiaries in Canada, USA and UK. Our software engineering group functions more or less as a startup of the parent company, addressing specific pain points in the telecoms industry. We apply lessons and tactics from the fast the fast moving consumer web to bring great UI/UX to the enterprise space.
We are small engineering team looking to expand rapidly by hiring smart people. Our focus is on keeping up with best practices and staying DRY. We strive to create a great culture where learning is just as important as “doing” (i.e. grunt work).
About You
You are software engineer with a desire to improve yourself. You enjoy working on challenging tasks but also knows that some grunt work needs to be done from time to time. You are ideally a full stack engineer who is as comfortable with the frontend as the backend. You enjoy reading up on best practises and keeping with the fast past world of web development. You should strive to write production ready code (DRY), but would be willing to go back to refactor when you feel it's necessary.
Technology Stack
- Python/Django
- AngularJS
- Redis
- Postgres
You will get to work with us in the heart of downtown Toronto on University Avenue. If this sounds interesting, please contact me: terryhong@gmail.com
I launched ScrumGenius (https://scrumgenius.com). Its a side project I started for fun at my previous job (it was just a simple slack bot script back then) and decided to actually build a service and launch it a few months ago. I did not take it too seriously at first, I was just using it to learn. However, after reading indiehackers and other people launching products I was really inspired to give it a try. Its been steadily growing and it makes around $300/mo.
Hoping to continue to grow it even more in 2018.
If anyone is looking for a end to end consultant that does Full Stack Dev with experience in mobile and web! Please do reach out, would love to talk! I am based in Canada and UK.