dark_pyrro

You have to check any payloads that you plan to use to see if GoHttp is required. Since you shouldn't run payloads "blindly", it will be obvious if it's required when you browse and learn the payload code for a specific payload. I haven't used it myself, it's easier to just run alternatives if needed (but it always depends on the use case what's relevant to use or not).

You can use it along with payloads and store things on it from the target perspective (but not store the payloads themselves on it, those needs to be stored on the internal storage of the Bunny).

Just the maintainer of that can answer if it's valid. Since it's based on/inspired by some work I did some years ago, I would say that it probably needs some tweaking to get up and running. However, I wouldn't walk down that path for different reasons. I would use a different Responder setup instead. Installing things via the tools directory of the Bunny (as described in the documentation) should still work as intended.

One way of getting less confused in that specific case is to not use the Micro SD card at all. I can't see that credentials would fill the internal storage of the Bunny. However, if you still want to use the Micro SD card with the Bunny, I guess you have to be more specific about what the confusion is all about. Why would you want to change the location? It's "dynamically" handled by the script, so I wouldn't try (or want) to change that.

Tried running it with sudo?

What USB cable are you using when connecting the Pineapple to the computer? The one that came with the Pineapple or something else? Tried different USB cables? Tried different USB ports on the computer (or other computers)?

Ask Ducky questions in the Ducky section of the forums.

Just to be sure; you mean that you've executed opkg update, nothing else? What's the output if you cat the GPS device? I.e. cat /dev/ttyAMC0 (assuming that is 100% verified to be the GPS device).

Legal cases or not, random device address is still a feature. And, no, I have no interest in scanning for BLE devices.

I would probably use the REST API. And, instead of using the log, I would most likely tell the Pineapple to capture ESSIDs to pool and then read from the pool using the API and display them on the big screen based on that API result. It depends on if you want ESSIDs to go away from the list after a while or not. You could read the log using the REST API as well, but I seem to remember that there is some bug linked to that specifically. Getting the system log is OK, but when following the API spec it just throws back errors when trying to get PineAP events from the log. There's an unofficial Ruby based "API" as well, but I guess it's best to stick with the officially supported way of doing things.

What tool(s)/language(s) are used when creating the payload?

I wouldn't be so sure about that. BLE uses MAC address randomization just like WiFi does (at least in some implementations) and will probably end up in a "non-vendor" result (just like you do when searching for WiFi related MAC addresses that are randomized).

Is there any specific "items" in the database (or log output) that you want to observe over time? Do you want to "monitor" it on the Pineapple or some device that is connected to the Pineapple? The use case needs to be a bit more detailed to be able to suggest possible ways to solve it all.

You need to be more specific. What have you learned this far? And, generally, this forum section is about the WiFi Pineapple Mark VII, not for cracking activities. It needs to be legit.

It might solve things, but I doubt it will change much. What you most likely need to do is to know how the VPS (and Turtle) is set up and adjust according to that scenario. Also, take things step by step and troubleshoot anything that might fail. Just starting from scratch isn't always the solution, but I won't try to stop you from doing it. Most important is that you document what you do so that it's possible to follow the steps you take when setting it all up again (as I suggested in my previous post). Coming back and say "I started from scratch and it's still not working" won't be any good input if trying to help you reach your goal. It has to be detailed.

This isn't the place to ask questions related to the Flipper Zero. This forum section is about the Hak5 USB Rubber Ducky "classic"/1st gen. Any "Ducky Script" related questions that's about knock-off (unlicensed) variants of Ducky Script should be discussed elsewhere. Only Ducky Script used with true Hak5 devices is relevant.

I would probably not accept a binary from a "1st poster" on a forum. However, I guess binwalk won't do the job. Have you tried to dissect it using IDA or Ghidra. It's kindof a way to "unpack" a binary (close, but not really, depends on the definition of "unpack" though).

I understand, language can be a barrier sometimes. You have to decide what area you want to operate in and specialize in that area of expertise. If you want to be able to "embrace" an as large customer base as possible, then select something common (web, Windows based environments, etc.). Next step is getting very good at those kind of "targets". Most of the time, you won't become a pentester (or equivalent) straight away. You need to build knowledge about the basic (and advanced) stuff before moving on to pure pentesting. There are of course other ways of reaching the goal, but I meet people (both online and "eye-to-eye") that might be good "script kiddies" but they have less or no clue about how things actually work and that is most often not a good combo if you want to get really good at things and do a good job. Since it's rather difficult to recruit people with proper knowledge, I try to use the tactics of promoting good tech and admin employees in my organization and add the security layer to their competence spectra, and they most often turn out to be really good cybersec resources. Then you of course need to add personal abilities to the mix, such as being eager to know things and never give up, and also prepare to put a lot of time into it.

Since the forums aren't official support, the chances of someone reading this (that has something to do with the Mark VII development) are low. If someone of importance would read, the chances would increase tremendously if posting in the Mark VII section of the forums instead of the section for the Mark IV.

The title of the thread is rather confusing. You see yourself as a pentester, but don't know where to start. That doesn't make sense to me. If you see yourself as a pentester, you should know where to start, otherwise you can't see yourself as a pentester... Anything else is just wishful thinking. The most obvious area to start is where your knowledge base is. Continue building on the knowledge that you already have and start applying the "security layer" to it all. From what you describe, it seems as if it's mainly related to software development (ish...)

I don't offer troubleshooting assistance in DM. Keep it in the open forums.

What ticket? If you've submitted a support ticket for a Mark IV Pineapple, I guess you have to wait until doomsday comes since the support for that product is long gone. The only supported Pineapples are the Mark VII (7) and Enterprise. In any case, this isn't official support (but instead a community of Hak5 device users), so you will likely not get any official response here anyway.

This should work (it at least does on one of my lab/test systems, not CAFR though) STRING This is a full string with a ^ SPACE SPACE STRING few d¨ead k^eys combo

Just configured the autossh module on one of my Turtles using my Lightsail VPS and I had no issues doing it. Not sure what you are doing. You have to be detailed (as in "step-by-step-detailed") in order to be able to troubleshoot at what point(s) you are doing something wrong.

OK, since you can't answer the questions, I just have to wish you good luck...