Jump to content

Johnny_Robot

Active Members
  • Posts

    13
  • Joined

  • Last visited

Posts posted by Johnny_Robot

  1. Hey guys,

    Great work on the Nano. I've been watching the videos for a few years now. Still nowhere near where I'd like to be technically, but I'm working on my development skills and would love to help out where I can in the development of the Nano. Thinking about joining the local maker/hacker space FamiLAB here to see if I can get some others involved locally as well. You said in the video there is a hangouts today. What time will this be happening? I'm on US Eastern time.

    ~JohnnyR030T

  2. Good info about Open Source firmware modifications like DD-WRT...

    https://www.fcc.gov/news-events/blog/2015/11/12/clearing-air-wi-fi-software-updates-0

    Clearing the Air on Wi-Fi Software Updates
    November 12, 2015 - 12:09 pm
    Julius Knapp | Chief, Office of Engineering & Technology

    This week marked the closing of the reply comment period in the Commission’s radio device approval modernization rulemaking. The comments and replies are largely supportive of the Commission’s proposals, but one particular element generated thousands of comments from individuals concerned that the proposal would encourage manufacturers to prevent modifications or updates to the software used in devices such as wireless local area networks (e.g., Wi-Fi routers). I’m pleased that this issue attracted considerable attention and thoughtful submissions into the record and would like to make it clear that the proposal is not intended to encourage manufacturers to prevent all modifications or updates to device software.

    As I wrote last month, this proceeding has taken on a significance beyond the Commission’s original intent. One of our key goals is to protect against harmful interference by calling on manufacturers to secure their devices against third party software modifications that would take a device out of its RF compliance. Yet, as the record shows, there is concern that our proposed rules could have the unintended consequence of causing manufacturers to “lock down” their devices and prevent all software modifications, including those impacting security vulnerabilities and other changes on which users rely. Eliciting this kind of feedback is the very reason that we sought comment in an NPRM and we are pleased to have received the feedback that will inform our decision-making on this matter.

    In my last post I recognized the need to work with stakeholders – particularly the user community – to address these concerns in a way that still enables the Commission to execute its mandate to protect users from harmful interference. I’m happy to say that the OET staff and I have spoken directly with some of these stakeholders in the last few weeks.

    One immediate outcome of this ongoing dialogue is a step we’ve taken to clarify our guidance on rules the Commission adopted last year in the U-NII proceeding. Our original lab guidance document released pursuant to that Order asked manufacturers to explain “how [its] device is protected from ‘flashing’ and the installation of third-party firmware such as DD-WRT”. This particular question prompted a fair bit of confusion – were we mandating wholesale blocking of Open Source firmware modifications?

    We were not, but we agree that the guidance we provide to manufacturers must be crystal-clear to avoid confusion. So, today we released a revision to that guidance to clarify that our instructions were narrowly-focused on modifications that would take a device out of compliance. The revised guidance now more accurately reflects our intent in both the U-NII rules as well as our current rulemaking, and we hope it serves as a guidepost for the rules as we move from proposal to adoption.

    There is more hard work ahead of us as we finalize rules, and we welcome continued input from manufacturers, users, technologists, and others.

  3. Hi Guys,

    So an interesting thing happened to me at a Red Box the other day. I already hate using them as it is. Long story short, when I slid my card the computer locked up and I saw the infamous "Application is not responding" window.. So obviously this is a Windows Server...

    I work in POS Retail and most card readers I've seen are basically just HID devices. This got me thinking... I was reading about a hack out there called the "BadBarCode hack" where basically the UPC code contains information so that when the employee scans the code with their scanner (Also just an HID device) it basically opens a shell on the machine and virtually types control commands like a rubber ducky would... Needless to say you can do a lot of things with a rubber ducky! :) So to get to the point... What would stop someone from creating a card with "Bad information" so that when they scan the card the card reader just runs the commands? It's kind of terrifying if something like this is possible! And how would you fix something like this?

    Love the show! Keep 'em coming! :)

    JohnnyR030T

    BadBarCode hack article:

    https://threatpost.com/one-badbarcode-spoils-whole-bunch/115362/

  4. Thanks overwraith. I don't have much experience with arduino (Although it sounds very interesting) I'm thinking that for the time being I may just use a batch script for the first part of the install and then plug the rubber ducky in after reboot. I'll look into arduino more though. :)

  5. Does anyone know a way to continue a rubber ducky script after rebooting the Windows7 OS?

    I'm trying to use the Ducky as a way to automate Machine setups. One of the first things I need to do is disable UAC and change the machine name and Workgroup. Then after that I have to reboot and need the script to pickup where it last left off.

  6. Hi guys,

    I was just wondering what affordable firewalls are the best out there. By affordable i mean preferably around $100 - 200 or less for a home network.

    there is just so much flaky non stable firmware and I want something that is secure as possible and would appreciate the feedback.

    Thanks

  7. Hi guys,

    I'm trying to learn bash scripting and I've got a little problem that I thought maybe you could help with. Here's the jest of it....

    I have a command line tool called "xprop"that displays the properties of an image file. "xprop" results look something like this...

    Image_name: This is the file name.

    Image_Resolution: This is the image resolution.

    Image_Channels: This is the number of image channels.

    Channel_Types: This is the channel types.

    Bit_Depth: This is the bit depths.

    My question is, using this "xprop" script file, what do you think the best way would be to display only the File name and Resolution that the "xprop" script returns for all the image files in my current directory, and then send that output data to a new text document?

    Any help would be amazing! ;) Thanks for this channel. It's amazing!

    peace

×
×
  • Create New...