Jump to content

digininja

Global Moderators
  • Posts

    4,005
  • Joined

  • Last visited

  • Days Won

    210

Posts posted by digininja

  1. "any thoughts?"

     

    Yes, ask them if it worked well and if it was easy to set up. If it was, check if it's compatible with your rig, if it is then you've found a card that will work. Log the specs and the price.

    Repeat the process with other recommendations from people with working cards then when you've got a few to compare, buy the best you can afford.

    What I'm trying to do is to save you from buying something that is recommended by people who don't really know what they are talking about or who don't have up to date knowledge of what is out there. Get to the Hashcat forums and ask on there, you'll get a much better set of replies from people who are actually using this kit.

  2. No. It is ones that support the features required by the tools that are to be  used. I don't know what the definition of a "Professional GPU" is but if it isn't supported by the cracking tool or the OS or the motherboard then it isn't going to be any use.

    Check the tool you want to use and then go to its site or forum and see what they recommend. That may be an amazing gaming GPU, it may be a dirt cheap "Professional" GPU that no one has ever heard of, it may be a pair of two cheap ones that do better than one single one.

  3. 6 minutes ago, haze1434 said:

    Also, I disagree. Modern gaming means that the graphics cards designed for this have to complete a lot of mathematical computations every second. Which is exactly what you want in a password cracking rig as well.

     

    I know this is way out of date but have a look at this thread from the Hashcat forum, it describes an Nvidia card which is better for gaming but is worse than the AMD equivalent for password cracking.

    https://hashcat.net/forum/thread-2181.html

    The same still holds true today, both types of cards are designed to do the same things but they do them in different ways, some work better for games, some for cracking.

  4. If you want to understand how exploits actually work then for a lot of them you'll need to learn to at least read different languages. Get yourself comfortable with Ruby and Python then go to exploit-db and pick some to play with. Most will have a link to the write up on how they were found and what they do. If you can read the source you should be able to start to understand what they are actually doing.

    If you have some cash to spend, look at the courses on SecurityTube, they do all sorts of good stuff.

  5. Depends on the situation, I'm on a test at the moment where I popped a box and managed to pull the local SAM. I brute forced that to get the password for an account that was reused across the network. This is a test being done quietly with only a couple of people in the security team aware it is going on, going to them to ask for the password isn't in the spirit of the test so I have to get it myself.

    Don't mix offline and online brute forcing, a lock out policy has no affect on offline brute forcing using GPUs and GPUs don't help with going for an OWA login.

  6. With a lot of hacking you could probably do it on the command line in bash but I'd do a ruby or python script to wrap it all. That can tail the file and parse anything you want out of it.

    If you want to use bash, look at cut, that will let you break the line down into bits which you can then reuse. Or sed might be better, you could use that to do match and replace to build a whole new command.

  7. Depends on the threat model, for secure comms I'll trust something like WhatsApp or Signal that has had a lot of peer reviews and is trusted by people I trust.

    If you are sure about your systems then open the source up, let it be peer reviewed, that is the only way to get complete trust.

  8. I'll happily hold my hand up and say that I'm no where near smart enough to build an app that I would recommend anyone uses to transmit or store sensitive information. To do that well takes a lot of work by people who know the field inside out.

    If you want to get the tinfoil hat out over monitoring of existing tools, how do we know that you aren't the CIA trying to get us to use your tool that has build in backdoors? Sometimes the most innocuous of errors, an = rather than == can make a huge difference.

  9. Basically ARP packets (not packages) are layer two and so don't leave their network segment. If it is a bridge, then it would probably be considered a flat network, everything on the same subnet, and so ARP packets would traverse all across it. If it is routing (acting as a NAT device) then packets would not traverse it.

    To work out if it is bridging or not, probably the easiest way is to look at the other devices on the network with you. If they are all wireless except the AP, then you are probably on a wifi subnet and so the AP is a router, if there are wired devices as well then it might be a flat network.

    You can also traceroute out of the network and look at the hops. If it goes from your internal IP to an external then it is likely a flat network, if there are multiple internal IPs before the external then there is some routing going on.

    Lots of possibly and likely there as there are always exceptions, you just have to learn to spot them.

×
×
  • Create New...