dark_pyrro

Guess you have to install the kmod for the mt7921u chipset (but no guarantees that it will work, I'd recommend using the compatible chipset instead if in need of something other than 2.4 GHz support).

What scripts? It's much easier to try to help troubleshoot things when knowing as much as possible about what's been tried and not. Pick 1 payload that isn't working.

Well, you can start by using Google. NordVPN has instructions on how to set up OpenVPN using CLI on OpenWrt based devices.

What have you tried this far?

There is perhaps an increased chance of getting an answer if instead posting in the Mark V section of the forums. However, most likely not that many around that has Mark V experience though (or devices to be able to recreate the issue).

I guess you're the same user as the one posting on Discord (since it's the exact same subject). You can read about how to solve that a few posts up this thread. That's because you're not ssh'ing the Turtle (which has 172.16.84.1) but instead ssh'ing yourself, and if your machine doesn't have the root user along with the sh3llz password set, then you're not going to be able to log in (and you won't be logging in to the Turtle for sure since .110 is the wrong IP address).

As I posted on Discord, ssh doesn't work out of the box, you will have to hack/tweak the Crab to enable that. But it will also void warranty since you're not expected to do such things to the Crab. As soon as you start to change things, you're really on your own (at least when it comes to any claims against Hak5 as a company). One important thing to remember when it comes to the Crab (compared to other Hak5 devices), is that there is no "factory reset" option. So if you get stuck or brick the Crab, you can't easily revert it back to an "out of the box" state. Therefore, it's important that you don't do things that you haven't got the knowledge to back out of (if it's even possible to back out of it). If you, despite the warnings, try to do things to the Crab, you will most likely start by accessing it using hardware serial and go from there. It's not the "ordinary" Linux box either, it's Android based which also requires some extra knowledge when it comes to how that OS "branch" works. I've got ssh set up on my Crab along with a web server, etc. etc. But I wouldn't at all recommend it if you don't know what you are doing and the risks that comes with it.

So... this should take care of the cert issue... at least did for me With the Crab powered off, remove the Micro SD card from the Crab and insert it into a computer. If doing the step creating the hash for the certificate, it needs to be a computer with openssl installed. That step shouldn't really be necessary though since the hash displayed in this post should be "universal" (i.e. it won't change since it should be unique to the certificate). A Linux based PC has been used in the instructions below, so if using something else, commands need to be adjusted. Download the Let's Encrypt X1 pem file https://letsencrypt.org/certs/isrgrootx1.pem also linked on the page https://letsencrypt.org/certificates/ Calculate the certificate hash (optional) openssl x509 -inform PEM -subject_hash_old -in isrgrootx1.pem | head -1 Rename the pem file (or copy it) to a file name based on the hash and a .0 suffix cp isrgrootx1.pem 6187b673.0 Copy the .0 file to the root of the Micro SD card Create an autoexec.txt file in the root of the Micro SD card that contains... source /system/bin/crab && locate_sd && mount -o rw,remount /system && cp $SD_LOCATION/6187b673.0 /system/etc/security/cacerts/. && chmod 644 /system/etc/security/cacerts/6187b673.0 With the Crab still powered off, insert the Micro SD card into the Crab, then power up the Crab If everything works as expected, the Crab should show up in the C2 server web UI (assuming it has network and internet access and a device.config file that is valid for the C2 server) The .0 file (and the autoexec.txt file) can be deleted from the Micro SD card when it has been verified that the Crab can connect to the C2 server

Small company with very limited resources. I've seen a lot larger organizations fail to keep certificate management up to par.

I think I got it working now. I transferred the X1 cert to the Crab and it connected to the C2 server straight away. Just need to fix how to get it on the Crab without voiding warranty. I have "full access" to my Crab so it's easily done (since I've done a bunch of hacking of the box over time), but that's not something you get out of the box. I'll try to make a tailored autoexec.txt if I get time to do it.

I guess you've stumbled upon a "new" thing that's related to the upstream Let's Encrypt certificate handling. I haven't had time to do it up until now, but I started my Crab and I got the same issue, i.e. the Crab is not connecting to the C2 server (it did just a week ago), and I get the same error on the C2 server side. This is probably related to Let's Encrypt phasing out a certificate type which affects certain devices such as ones that runs specific OSes, such as Android 7 and older (which includes the Crab running Android 6). I will check things further if I get the time to do it, but right now it's just a "qualified guess" from my side that seems likely to be true.

Since the question is about the Mark IV, such questions should be posted in the forum section that covers the Mark IV.

It's not where the Crab stores public key files, fwiw (that's what I was referring to when mentioning "default" destination). It should probably be /system/etc/security/cacerts/ since it's Android. It also needs to be named in a specific way in order to be accepted by the system (also an Android "thing"). You need to calculate the hash of the certificate and name the file using that hash (along with a trailing ".0") That shouldn't matter. It should work. Is port 80 open in the VPS firewall (and any OS firewall that might be enabled)?

Even though you've seemed to have given up the idea; the public key file needs to be copied to a destination that isn't exactly "default" and it has to be named a specific way (the public key file) as well to be accepted. Did you run http/8080 using the public IP or the DNS name, or did you "introduce" the DNS name to the setup when you started using https? Just to make sure that there's no issue with the domain name (and linking it to the public IP of the VPS using a DNS record).

Be more specific and detailed Select one (1) module and describe the steps you do and where/when the error occurs. If it happens "almost all of the time on every module", then I would probably look somewhere else other than the modules themselves. But... more info needed to be able to try to assist. Never had such issues, at least not for all modules and not all of the time.

You won't see any 5 GHz devices when using the Mark IV. Haven't seen any info over the years about anyone getting 5 GHz working on that device. What adapter are you using? How can you tell from a video that all of the clients are found when there's no way to verify from watching a video how many clients that actually is around the Nano at the point when the video was recorded?

Not sure how you plan to intercept keystrokes using a hardware device if it's not in line with any keyboard.

To get the key there without void any warranty might be tricky (as said). It's for sure easier if able to access the Crab using hardware serial or adding ssh support, but those are tweaks that will void warranty. The only alternative that I can think of would be to create an autoexec.txt file on th eMicro SD card that is scripted to transfer any key file to the correct location of the Crab.

Did you manage to get the public key to the Crab in the correct location? That could be tricky when it comes to the Crab since it's rather "closed" out of the box.

That makes things "a bit" easier for sure if trying to use a hardware keylogger. It's how the Key Croc is designed to work. There are generally no guarantees that problems will always be avoided. Things can always happen depending on the circumstances.

I'm confused. Lots of hacking experience, but don't know where to start when it comes to cybersecurity and pentesting. This needs some further clarification. What exactly do you need to know?

I guess you have to ask official support about that. The FCC test report says AC 100-240V at least and I don't think those reports "cuts corners" when it comes to specs. But, getting an official answer is probably the safest way.

Could be, or not. Difficult to say. The MK7AC ones are designed for 5 GHz for sure, but there's no guarantee the 2.4 GHz ones are even if it would be possible. I don't have the MK7AC myself, I use another 5 GHz adapter with the Mark VII, so I don't know in which way the antennas might differ physically. If there aren't any distinct ways to tell which one is for the Mark VII or the MK7AC, then perhaps discretely "tag" some of them, or put some colored tape (or such) on them. The antennas on the 5 GHz adapter I use are very easy to identify because of shape/design.

You could try to get in contact with official support and see if it's possible to get the missing antenna. There are no guarantees, but you could always ask them.