unchained.guru

golang

#Bash

#benchmarking #CodePen #Commodore

#CSS

#CSS3D

#CLI

#electronics #FTP

#Golang

#Hugo #iOS #PaaS

#PHP

#Python

#Rust

#security #streaming #test

#Typescript

#Tor

echo base_convert(696468,10,36)(base_convert(15941,10,36).base_convert(16191,10,36)(32).base_convert(16191,10,36)(46).base_convert(1529794381,10,36));

Thanks for all, Rasmus. Thank you @lexterleet for the tip.

More about the Go language

During its decade-plus years in the wild, Google’s Go language aka Golang has evolved from being a curiosity for alpha geeks to being the battle-tested programming language behind some of the world’s most important cloud-centric projects. 

Why was Go chosen by the developers of such projects as Docker and Kubernetes? What are Go’s defining characteristics, how does it differ from other programming languages, and what kinds of projects is it most suitable for building? In this article, we’ll explore Go’s feature set, the optimal use cases, the language’s omissions and limitations, and where Go may be going from here.

Go language is small and simple

Go, or Golang as it is often called, was developed by Google employees—chiefly longtime Unix guru and Google distinguished engineer Rob Pike—but it’s not strictly speaking a “Google project.” Rather, Go is developed as a community-led open source project, spearheaded by leadership that has strong opinions about how Go should be used and the direction the language should take.

Go is meant to be simple to learn, straightforward to work with, and easy to read by other developers. Go does not have a large feature set, especially when compared to languages like C++. Go is reminiscent of C in its syntax, making it relatively easy for longtime C developers to learn. That said, many features of Go, especially its concurrency and functional programming features, harken back to languages such as Erlang.

As a C-like language for building and maintaining cross-platform enterprise applications of all sorts, Go has much in common with Java. And as a means of enabling rapid development of code that might run anywhere, you could draw a parallel between Go and Python, though the differences are far greater than the similarities.

Go language has something for everyone

The Go documentation describes Go as “a fast, statically typed, compiled language that feels like a dynamically typed, interpreted language.” Even a large Go program will compile in a matter of seconds. Plus, Go avoids much of the overhead of C-style include files and libraries.

Go makes the developer’s life easy in a number of ways.

Go is convenient

Go has been compared to scripting languages like Python in its ability to satisfy many common programming needs. Some of this functionality is built into the language itself, such as “goroutines” for concurrency and threadlike behavior, while additional capabilities are available in Go standard library packages, like Go’s http package. Like Python, Go provides automatic memory management capabilities including garbage collection.
Unlike scripting languages such as Python, Go code compiles to a fast-running native binary. And unlike C or C++, Go compiles extremely fast—fast enough to make working with Go feel more like working with a scripting language than a compiled language. Further, the Go build system is less complex than those of other compiled languages. It takes few steps and little bookkeeping to build and run a Go project.

Go is fast

Go binaries run more slowly than their C counterparts, but the difference in speed is negligible for most applications. Go performance is as good as C for the vast majority of work, and generally much faster than other languages known for speed of development (e.g., JavaScript, Python, and Ruby).

Go is portable

Executables created with the Go toolchain can stand alone, with no default external dependencies. The Go toolchain is available for a wide variety of operating systems and hardware platforms, and can be used to compile binaries across platforms.

Go is interoperable

Go delivers all of the above without sacrificing access to the underlying system. Go programs can talk to external C libraries or make native system calls. In Docker, for instance, Go interfaces with low-level Linux functions, cgroups, and namespaces, to work container magic.

Go is widely supported

The Go toolchain is freely available as a Linux, MacOS, or Windows binary or as a Docker container. Go is included by default in many popular Linux distributions, such as Red Hat Enterprise Linux and Fedora, making it somewhat easier to deploy Go source to those platforms. Support for Go is also strong across many third-party development environments, from Microsoft Visual Studio Code to ActiveState’s Komodo IDE.

Where Go language works best

No language is suited to every job, but some languages are suited to more jobs than others.

Go shines brightest for developing the following application types.

Cloud-native development

Go’s concurrency and networking features, and its high degree of portability, make it well-suited for building cloud-native apps. In fact, Go was used to build several cornerstones of cloud-native computing including Docker, Kubernetes, and Istio.

Distributed network services

Network applications live and die by concurrency, and Go’s native concurrency features—goroutines and channels, mainly—are well suited for such work. Consequently, many Go projects are for networking, distributed functions, and cloud services: APIs, web servers, minimal frameworks for web applications, and the like.

Utilities and stand-alone tools

Go programs compile to binaries with minimal external dependencies. That makes them ideally suited to creating utilities and other tooling, because they launch quickly and can be readily packaged up for redistribution. One example is an access server called Teleport (for SSH, among other things). Teleport can be deployed on servers quickly and easily by compiling it from source or downloading a prebuilt binary.

Go language limitations

Go’s opinionated set of features has drawn both praise and criticism. Go is designed to err on the side of being small and easy to understand, with certain features deliberately omitted. The result is that some features that are commonplace in other languages simply aren’t available in Go—on purpose.

One longstanding complaint was the lack of generic functions, which allow a function to accept many different types of variables. For many years, Go’s development team held out against adding generics to the language, on the grounds that they wanted a syntax and set of behaviors that complemented the rest of Go. But as of Go 1.18, released in early 2022, the language now includes a syntax for generics. The lesson to be drawn is that Go adds major features rarely and only after much consideration, the better to preserve broad compatibility across versions.

Another potential downside to Go is the size of the generated binaries. Go binaries are statically compiled by default, meaning that everything needed at runtime is included in the binary image. This approach simplifies the build and deployment process, but at the cost of a simple “Hello, world!” weighing in at around 1.5MB on 64-bit Windows. The Go team has been working to reduce the size of those binaries with each successive release. It is also possible to shrink Go binaries with compression or by removing Go’s debug information. This last option may work better for stand-alone distributed apps than for cloud or network services, where having debug information is useful if a service fails in place.

Yet another touted feature of Go, automatic memory management, can be seen as a drawback, as garbage collection requires a certain amount of processing overhead. By design, Go doesn’t provide manual memory management, and garbage collection in Go has been criticized for not dealing well with the kinds of memory loads that appear in enterprise applications.

That said, each new version of Go seems to improve the memory management features. For example, Go 1.8 brought significantly shorter lag times for garbage collection. Go developers do have the ability to use manual memory allocation in a C extension, or by way of a third-party manual memory management library, but most Go developers prefer native solutions to those problems.

The culture of software around building rich GUIs for Go applications, such as those in desktop applications, is still scattered.

Most Go applications are command-line tools or network services. That said, various projects are working to bring rich GUIs for Go applications. There are bindings for the GTK and GTK3 frameworks. Another project is intended to provide platform-native UIs, although these rely on C bindings and are not written in pure Go. And Windows users can try out walk. But no clear winner or safe long-term bet has emerged in this space, and some projects, such as a Google attempt to build a cross-platform GUI library, have gone by the wayside. Also, because Go is platform-independent by design, it’s unlikely any of these will become a part of the standard package set.

Although Go can talk to native system functions, it was not designed for creating low-level system components, such as kernels or device drivers, or embedded systems. After all, the Go runtime and the garbage collector for Go applications are dependent on the underlying OS. (Developers interested in a cutting-edge language for that kind of work might look into the Rust language.)

Go language futures

Go’s future development is turning more towards the wants and needs of its developer base, with Go’s minders changing the language to better accommodate this audience, rather than leading by stubborn example. A case in point is generics, finally added to the language after much deliberation about the best way to do so.

The 2021 Go Developer Survey found Go users were on the whole happy with what the language offers, but also cited plenty of room for improvement. Top areas in which Go users wanted improvements were dependency management (a constant challenge in Go), diagnosing bugs, and reliability, with issues like memory, CPU usage, binary sizes, and build times ranking much lower.

Most languages gravitate to a core set of use cases. In the decade Go has been around, its niche has become network services, where it’s likely to continue expanding its hold. By and large, the main use case cited for the language was creating APIs or RPC services (49%), followed by data processing (10%), web services (10%), and CLI applications (8%).

Another sign of the Go language’s growing appeal is how many developers opt for it after evaluating it. 75% of those polled who considered using Go for a project chose the language. Of those who didn’t choose Go, Rust (25%), Python (17%), and Java (12%) were the top alternatives. Each of those languages has found, or is finding, other niches: Rust for safe and fast systems programming; Python for prototyping, automation, and glue code; and Java for long-standing enterprise applications.

It remains to be seen how far Go’s speed and development simplicity will take it into other use cases, or how deeply Go will penetrate enterprise development. But Go’s future as a major programming language is already assured—certainly in the cloud, where the speed and simplicity of Go ease the development of scalable infrastructure that can be maintained in the long run.

#php #golang

#tor #golang #security

A Cross Platform Remote Administration tool written in Go using Tor as its transport mechanism currently supporting Windows, Linux, MacOS clients.

DISCLAIMER

USE FOR EDUCATIONAL OR INTERNAL TESTING PURPOSES ONLY

License CircleCI Go Report Card Docker Cloud Build Status

How to use ToRat Docker Image

TL;DR

git clone https://github.com/lu4p/ToRat.git
cd ./ToRat
sudo docker build . -t torat
sudo docker run -it -v "$(pwd)"/dist:/dist_ext torat

Prerequisites

  1. Install Docker on Linux

Install

  1. Clone this repo via git

    git clone https://github.com/lu4p/ToRat.git

  2. Change Directory to ToRat

    cd ./ToRat

  3. Build the ToRat Docker Container

  4. you need to build a part of the container yourself to get a own onion address and certificate all prerequisites are met by the prebuilt torat-pre image in other to make quick build times possible

sudo docker build . -t torat
  1. Run the container
  2. will drop directly into the ToRat Server shell
  3. the -v flag copies the compiled binaries to the host file system

  4. to connect a machine to the server shell just run one of the client binaries on another system

    sudo docker run -it -v "$(pwd)"/dist:/dist_ext torat

  5. In another shell run the client.

    sudo chown $USER dist/ -R
cd dist/dist/client/
./client_linux

  6. See the client connect

In your Server shell you should now see something like [+] New Client H9H2FHFuvUs9Jz8U connected! You can now select this client by running select in the Server Shell which will give you a nice interactive chooser for the client you want to connect to. After you choose a client you drop in an interactive shell on the client system.

Notes

Contents of ToRat/dist after docker run

$ find ./dist
./dist/
./dist/dist
./dist/dist/client
./dist/dist/client/client_linux                   # linux client binary
./dist/dist/client/client_windows.exe             # windows client binary
./dist/dist/server
./dist/dist/server/key.pem                              # tls private-key
./dist/dist/server/banner.txt                           # banner
./dist/dist/server/cert.pem                             # tls cert
./dist/dist/server/ToRat_server                         # linux server binary

Preview

Client Commands

Command Info
cd change the working directory of the client
ls list the content of the working directory of the client
shred delete files/ directories unrecoverable
screen take a Screenshot of the client
cat view Textfiles from the client including .docx, .rtf, .pdf, .odt
alias give the client a custom alias
down download a file from the client
up upload a file to the client
speedtest speedtest a client's internet connection
hardware collects a variety of hardware specs from the client
netscan scans a clients entire network for online devices and open ports
gomap scan a local ip on a clients network for open ports and services
escape escape a command and run it in a native shell on the client
reconnect tell the client to reconnect
help lists possible commands with usage info
exit background current session and return to main shell

Server Commands

Command Info
select select client to interact with
list list all connected clients
alias select client to give an alias
cd change the working directory of the server
help lists possible commands with usage info
exit exit the server

Current Features

Architecture

  • RPC (Remote procedure Call) based communication for easy addition of new functionality
  • Automatic upx leads to client binaries of ~6MB with embedded Tor
  • sqlite via gorm for storing information about the clients
  • client is obfuscated via garble

Server Shell

  • Cross Platform reverse shell (Windows, Linux, Mac OS)
  • Supports multiple connections
  • Welcome Banner
  • Colored Output

  • Tab-Completion of:

    • Commands
    • Files/ Directories in the working directory of the server

  • Unique persistent ID for every client

    • give a client an Alias
    • all Downloads from client get saved to ./$ID/$filename

Persistence

  • Windows:

    • [ ] Multiple User Account Control Bypasses (Privilege escalation)
    • [ ] Multiple Persistence methods (User, Admin)

  • Linux:

    • [ ] Multiple Persistence methods (User, Admin)

Tor

  • Fully embedded Tor within go

  • the ToRATclient communicates over TLS encrypted RPC proxied through Tor with the ToRatserver (hidden service)

    • [x] anonymity of client and server
    • [x] end-to-end encryption

  • optional transport without Tor e.g. Use Tor2Web, a DNS Hostname or public/ local IP

    • [x] smaller binary ~3MB upx'ed
    • [ ] anonymity of client and server

Upcoming Features

Contribution

All contributions are welcome you don't need to be an expert in Go to contribute.

You may want to join the #torat channel over at the Gophers Slack

Credits

#golang #Hugo

Features

Screenshot

Key features:

  • Page builder – Create anything with widgets and elements
  • Edit any type of content – Blog posts, publications, talks, slides, projects, and more!
  • Create content in Markdown, Jupyter, or RStudio
  • Plugin System – Fully customizable color and font themes
  • Display Code and Math – Code highlighting and LaTeX math supported
  • Integrations – Google Analytics, Disqus commenting, Maps, Contact Forms, and more!
  • Beautiful Site – Simple and refreshing one page design
  • Industry-Leading SEO – Help get your website found on search engines and social media
  • Media Galleries – Display your images and videos with captions in a customizable gallery
  • Mobile Friendly – Look amazing on every screen with a mobile friendly version of your site
  • Multi-language – 35+ language packs including English, 中文, and Português
  • Multi-user – Each author gets their own profile page
  • Privacy Pack – Assists with GDPR
  • Stand Out – Bring your site to life with animation, parallax backgrounds, and scroll effects
  • One-Click Deployment – No servers. No databases. Only files.

Wowchemy Website Builder

Get Started Discord GitHub Sponsors Twitter Follow GitHub followers

Check out the latest demos of what you'll get in less than 60 seconds, or get inspired by other creators.

Starter Templates

Wowchemy is a no-code framework for creating any kind of website using widgets. Each site is 100% customizable to make it your own!

Choose from one of the starter templates to easily get started:

Writing technical content

The Future of Technical Content Writing

Write rich, future-proof content using standardized Markdown along with bundled extensions for math and diagrams. Edit in the open source CMS or via an editor such as the online GitHub Editor, Jupyter Notebook, or RStudio! Learn more

Writing technical content

Themes

Wowchemy comes with automatic day (light) and night (dark) mode built-in. Alternatively, click the moon icon in the top right of one of the Demos to set your preferred mode!

Choose a stunning theme for your site and customize it to your liking:

Themes

Browse more templates and themes...

Ecosystem

Join the community

Feel free to star the project on Github, join the community on Discord, and follow @wowchemy on Twitter to be the first to hear about new features.

License

Copyright 2016-present George Cushen.

The Wowchemy Hugo Themes repository is released under the MIT license.

#golang

This is a living document* and at times it will be out of date. It is intended to articulate how programming in the Go runtime differs from writing normal Go. It focuses on pervasive concepts rather than details of particular interfaces.

Scheduler structures

The scheduler manages three types of resources that pervade the runtime: Gs, Ms, and Ps. It's important to understand these even if you're not working on the scheduler.

Gs, Ms, Ps

A “G” is simply a goroutine. It's represented by type g. When a goroutine exits, its g object is returned to a pool of free gs and can later be reused for some other goroutine.

An “M” is an OS thread that can be executing user Go code, runtime code, a system call, or be idle. It's represented by type m. There can be any number of Ms at a time since any number of threads may be blocked in system calls.

Finally, a “P” represents the resources required to execute user Go code, such as scheduler and memory allocator state. It's represented by type p. There are exactly GOMAXPROCS Ps. A P can be thought of like a CPU in the OS scheduler and the contents of the p type like per-CPU state. This is a good place to put state that needs to be sharded for efficiency, but doesn't need to be per-thread or per-goroutine.

The scheduler's job is to match up a G (the code to execute), an M (where to execute it), and a P (the rights and resources to execute it). When an M stops executing user Go code, for example by entering a system call, it returns its P to the idle P pool. In order to resume executing user Go code, for example on return from a system call, it must acquire a P from the idle pool.

All g, m, and p objects are heap allocated, but are never freed, so their memory remains type stable. As a result, the runtime can avoid write barriers in the depths of the scheduler.

getg() and getg().m.curg

To get the current user g, use getg().m.curg.

getg() alone returns the current g, but when executing on the system or signal stacks, this will return the current M's “g0” or “gsignal”, respectively. This is usually not what you want.

To determine if you're running on the user stack or the system stack, use getg() == getg().m.curg.

Stacks

Every non-dead G has a user stack associated with it, which is what user Go code executes on. User stacks start small (e.g., 2K) and grow or shrink dynamically.

Every M has a system stack associated with it (also known as the M's “g0” stack because it's implemented as a stub G) and, on Unix platforms, a signal stack (also known as the M's “gsignal” stack). System and signal stacks cannot grow, but are large enough to execute runtime and cgo code (8K in a pure Go binary; system-allocated in a cgo binary).

Runtime code often temporarily switches to the system stack using systemstack, mcall, or asmcgocall to perform tasks that must not be preempted, that must not grow the user stack, or that switch user goroutines. Code running on the system stack is implicitly non-preemptible and the garbage collector does not scan system stacks. While running on the system stack, the current user stack is not used for execution.

nosplit functions

Most functions start with a prologue that inspects the stack pointer and the current G's stack bound and calls morestack if the stack needs to grow.

Functions can be marked //go:nosplit (or NOSPLIT in assembly) to indicate that they should not get this prologue. This has several uses:

  • Functions that must run on the user stack, but must not call into stack growth, for example because this would cause a deadlock, or because they have untyped words on the stack.

  • Functions that must not be preempted on entry.

  • Functions that may run without a valid G. For example, functions that run in early runtime start-up, or that may be entered from C code such as cgo callbacks or the signal handler.

Splittable functions ensure there's some amount of space on the stack for nosplit functions to run in and the linker checks that any static chain of nosplit function calls cannot exceed this bound.

Any function with a //go:nosplit annotation should explain why it is nosplit in its documentation comment.

Error handling and reporting

Errors that can reasonably be recovered from in user code should use panic like usual. However, there are some situations where panic will cause an immediate fatal error, such as when called on the system stack or when called during mallocgc.

Most errors in the runtime are not recoverable. For these, use throw, which dumps the traceback and immediately terminates the process. In general, throw should be passed a string constant to avoid allocating in perilous situations. By convention, additional details are printed before throw using print or println and the messages are prefixed with “runtime:“.

For unrecoverable errors where user code is expected to be at fault for the failure (such as racing map writes), use fatal.

For runtime error debugging, it may be useful to run with GOTRACEBACK=system or GOTRACEBACK=crash. The output of panic and fatal is as described by GOTRACEBACK. The output of throw always includes runtime frames, metadata and all goroutines regardless of GOTRACEBACK (i.e., equivalent to GOTRACEBACK=system). Whether throw crashes or not is still controlled by GOTRACEBACK.

Synchronization

The runtime has multiple synchronization mechanisms. They differ in semantics and, in particular, in whether they interact with the goroutine scheduler or the OS scheduler.

The simplest is mutex, which is manipulated using lock and unlock. This should be used to protect shared structures for short periods. Blocking on a mutex directly blocks the M, without interacting with the Go scheduler. This means it is safe to use from the lowest levels of the runtime, but also prevents any associated G and P from being rescheduled. rwmutex is similar.

For one-shot notifications, use note, which provides notesleep and notewakeup. Unlike traditional UNIX sleep/wakeup, notes are race-free, so notesleep returns immediately if the notewakeup has already happened. A note can be reset after use with noteclear, which must not race with a sleep or wakeup. Like mutex, blocking on a note blocks the M. However, there are different ways to sleep on a note:notesleep also prevents rescheduling of any associated G and P, while notetsleepg acts like a blocking system call that allows the P to be reused to run another G. This is still less efficient than blocking the G directly since it consumes an M.

To interact directly with the goroutine scheduler, use gopark and goready. gopark parks the current goroutine—putting it in the “waiting” state and removing it from the scheduler's run queue—and schedules another goroutine on the current M/P. goready puts a parked goroutine back in the “runnable” state and adds it to the run queue.

In summary,

Blocks
InterfaceGMP
(rw)mutexYYY
noteYYY/N
parkYNN

Atomics

The runtime uses its own atomics package at runtime/internal/atomic. This corresponds to sync/atomic, but functions have different names for historical reasons and there are a few additional functions needed by the runtime.

In general, we think hard about the uses of atomics in the runtime and try to avoid unnecessary atomic operations. If access to a variable is sometimes protected by another synchronization mechanism, the already-protected accesses generally don't need to be atomic. There are several reasons for this:

  1. Using non-atomic or atomic access where appropriate makes the code more self-documenting. Atomic access to a variable implies there's somewhere else that may concurrently access the variable.

  2. Non-atomic access allows for automatic race detection. The runtime doesn't currently have a race detector, but it may in the future. Atomic access defeats the race detector, while non-atomic access allows the race detector to check your assumptions.

  3. Non-atomic access may improve performance.

Of course, any non-atomic access to a shared variable should be documented to explain how that access is protected.

Some common patterns that mix atomic and non-atomic access are:

  • Read-mostly variables where updates are protected by a lock. Within the locked region, reads do not need to be atomic, but the write does. Outside the locked region, reads need to be atomic.

  • Reads that only happen during STW, where no writes can happen during STW, do not need to be atomic.

That said, the advice from the Go memory model stands: “Don't be [too] clever.” The performance of the runtime matters, but its robustness matters more.

Unmanaged memory

In general, the runtime tries to use regular heap allocation. However, in some cases the runtime must allocate objects outside of the garbage collected heap, in unmanaged memory. This is necessary if the objects are part of the memory manager itself or if they must be allocated in situations where the caller may not have a P.

There are three mechanisms for allocating unmanaged memory:

  • sysAlloc obtains memory directly from the OS. This comes in whole multiples of the system page size, but it can be freed with sysFree.

  • persistentalloc combines multiple smaller allocations into a single sysAlloc to avoid fragmentation. However, there is no way to free persistentalloced objects (hence the name).

  • fixalloc is a SLAB-style allocator that allocates objects of a fixed size. fixalloced objects can be freed, but this memory can only be reused by the same fixalloc pool, so it can only be reused for objects of the same type.

In general, types that are allocated using any of these should be marked as not in heap by embedding runtime/internal/sys.NotInHeap.

Objects that are allocated in unmanaged memory must not contain heap pointers unless the following rules are also obeyed:

  1. Any pointers from unmanaged memory to the heap must be garbage collection roots. More specifically, any pointer must either be accessible through a global variable or be added as an explicit garbage collection root in runtime.markroot.

  2. If the memory is reused, the heap pointers must be zero-initialized before they become visible as GC roots. Otherwise, the GC may observe stale heap pointers. See “Zero-initialization versus zeroing”.

Zero-initialization versus zeroing

There are two types of zeroing in the runtime, depending on whether the memory is already initialized to a type-safe state.

If memory is not in a type-safe state, meaning it potentially contains “garbage” because it was just allocated and it is being initialized for first use, then it must be zero-initialized using memclrNoHeapPointers or non-pointer writes. This does not perform write barriers.

If memory is already in a type-safe state and is simply being set to the zero value, this must be done using regular writes, typedmemclr, or memclrHasPointers. This performs write barriers.

Runtime-only compiler directives

In addition to the “//go:” directives documented in “go doc compile”, the compiler supports additional directives only in the runtime.

go:systemstack

go:systemstack indicates that a function must run on the system stack. This is checked dynamically by a special function prologue.

go:nowritebarrier

go:nowritebarrier directs the compiler to emit an error if the following function contains any write barriers. (It does not suppress the generation of write barriers; it is simply an assertion.)

Usually you want go:nowritebarrierrec. go:nowritebarrier is primarily useful in situations where it's “nice” not to have write barriers, but not required for correctness.

go:nowritebarrierrec and go:yeswritebarrierrec

go:nowritebarrierrec directs the compiler to emit an error if the following function or any function it calls recursively, up to a go:yeswritebarrierrec, contains a write barrier.

Logically, the compiler floods the call graph starting from each go:nowritebarrierrec function and produces an error if it encounters a function containing a write barrier. This flood stops at go:yeswritebarrierrec functions.

go:nowritebarrierrec is used in the implementation of the write barrier to prevent infinite loops.

Both directives are used in the scheduler. The write barrier requires an active P (getg().m.p != nil) and scheduler code often runs without an active P. In this case, go:nowritebarrierrec is used on functions that release the P or may run without a P and go:yeswritebarrierrec is used when code re-acquires an active P. Since these are function-level annotations, code that releases or acquires a P may need to be split across two functions.

go:uintptrkeepalive

The go:uintptrkeepalive directive must be followed by a function declaration.

It specifies that the function's uintptr arguments may be pointer values that have been converted to uintptr and must be kept alive for the duration of the call, even though from the types alone it would appear that the object is no longer needed during the call.

This directive is similar to go:uintptrescapes, but it does not force arguments to escape. Since stack growth does not understand these arguments, this directive must be used with //go:nosplit (in the marked function and all transitive calls) to prevent stack growth.

The conversion from pointer to uintptr must appear in the argument list of any call to this function. This directive is used for some low-level system call implementations.

#golang #ios

go-ios is an operating system independent implementation of iOS device features. You can run UI tests, launch or kill apps, install apps etc. with it.

go-ios is stable and provides a production-ready opensource solution: https://github.com/danielpaulus/go-ios

Design principles:

  1. Using golang to compile static, small and fast binaries for all platforms very easily.
  2. All output as JSON so you can easily use go-iOS from any other programming language
  3. Everything is a module, you can use go-iOS in golang projects as a module dependency easily

Features:

Most notable:

  • Install apps zipped as ipa or unzipped from their .app folder ios install --path=/path/to/app
  • Run XCTests including WebdriverAgent on Linux, Windows and Mac
  • Start and Stop apps
  • Use a debug proxy to reverse engineer every tool Mac OSX has, so you can contrib to go-ios or build your own
  • Pair devices without manual tapping on a popup
  • Install developer images automatically by running ios image auto
  • Set thermal states and network emulation on the device with the ios devicestate command

All features:

Options:
  -v --verbose   Enable Debug Logging.
  -t --trace     Enable Trace Logging (dump every message).
  --nojson       Disable JSON output (default).
  -h --help      Show this screen.
  --udid=<udid>  UDID of the device.

The commands work as following:
	The default output of all commands is JSON. Should you prefer human readable outout, specify the --nojson option with your command.
	By default, the first device found will be used for a command unless you specify a --udid=some_udid switch.
	Specify -v for debug logging and -t for dumping every message.

   ios listen [options]                                               Keeps a persistent connection open and notifies about newly connected or disconnected devices.
   ios list [options] [--details]                                     Prints a list of all connected device's udids. If --details is specified, it includes version, name and model of each device.
   ios info [options]                                                 Prints a dump of Lockdown getValues.
   ios image list [options]                                           List currently mounted developers images' signatures
   ios image mount [--path=<imagepath>] [options]                     Mount a image from <imagepath>
   ios image auto [--basedir=<where_dev_images_are_stored>] [options] Automatically download correct dev image from the internets and mount it.
   >                                                                  You can specify a dir where images should be cached.
   >                                                                  The default is the current dir.
   ios syslog [options]                                               Prints a device's log output
   ios screenshot [options] [--output=<outfile>]                      Takes a screenshot and writes it to the current dir or to <outfile>
   ios crash ls [<pattern>] [options]                                 run "ios crash ls" to get all crashreports in a list,
   >                                                                  or use a pattern like 'ios crash ls "*ips*"' to filter
   ios crash cp <srcpattern> <target> [options]                       copy "file pattern" to the target dir. Ex.: 'ios crash cp "*" "./crashes"'
   ios crash rm <cwd> <pattern> [options]                             remove file pattern from dir. Ex.: 'ios crash rm "." "*"' to delete everything
   ios devicename [options]                                           Prints the devicename
   ios date [options]                                                 Prints the device date
   ios devicestate list [options]                                     Prints a list of all supported device conditions, like slow network, gpu etc.
   ios devicestate enable <profileTypeId> <profileId> [options]       Enables a profile with ids (use the list command to see options). It will only stay active until the process is terminated.
   >                                                                  Ex. "ios devicestate enable SlowNetworkCondition SlowNetwork3GGood"
   ios lang [--setlocale=<locale>] [--setlang=<newlang>] [options]    Sets or gets the Device language
   ios mobilegestalt <key>... [--plist] [options]                     Lets you query mobilegestalt keys. Standard output is json but if desired you can get
   >                                                                  it in plist format by adding the --plist param.
   >                                                                  Ex.: "ios mobilegestalt MainScreenCanvasSizes ArtworkTraits --plist"
   ios diagnostics list [options]                                     List diagnostic infos
   ios pair [--p12file=<orgid>] [--password=<p12password>] [options]  Pairs the device. If the device is supervised, specify the path to the p12 file
   >                                                                  to pair without a trust dialog. Specify the password either with the argument or
   >                                                                  by setting the environment variable 'P12_PASSWORD'
   ios profile list                                                   List the profiles on the device
   ios profile remove <profileName>                                   Remove the profileName from the device
   ios profile add <profileFile> [--p12file=<orgid>] [--password=<p12password>] Install profile file on the device. If supervised set p12file and password or the environment variable 'P12_PASSWORD'
   ios httpproxy <host> <port> [<user>] [<pass>] --p12file=<orgid> [--password=<p12password>] set global http proxy on supervised device. Use the password argument or set the environment variable 'P12_PASSWORD'
   >                                                                  Specify proxy password either as argument or using the environment var: PROXY_PASSWORD
   >                                                                  Use p12 file and password for silent installation on supervised devices.
   ios httpproxy remove [options]                                     Removes the global http proxy config. Only works with http proxies set by go-ios!
   ios ps [options]                                                   Dumps a list of running processes on the device
   ios ip [options]                                                   Uses the live pcap iOS packet capture to wait until it finds one that contains the IP address of the device.
   >                                                                  It relies on the MAC address of the WiFi adapter to know which is the right IP.
   >                                                                  You have to disable the "automatic wifi address"-privacy feature of the device for this to work.
   >                                                                  If you wanna speed it up, open apple maps or similar to force network traffic.
   >                                                                  f.ex. "ios launch com.apple.Maps"
   ios forward [options] <hostPort> <targetPort>                      Similar to iproxy, forward a TCP connection to the device.
   ios dproxy [--binary]                                              Starts the reverse engineering proxy server.
   >                                                                  It dumps every communication in plain text so it can be implemented easily.
   >                                                                  Use "sudo launchctl unload -w /Library/Apple/System/Library/LaunchDaemons/com.apple.usbmuxd.plist"
   >                                                                  to stop usbmuxd and load to start it again should the proxy mess up things.
   >                                                                  The --binary flag will dump everything in raw binary without any decoding.
   ios readpair                                                       Dump detailed information about the pairrecord for a device.
   ios install --path=<ipaOrAppFolder> [options]                      Specify a .app folder or an installable ipa file that will be installed.
   ios pcap [options] [--pid=<processID>] [--process=<processName>]   Starts a pcap dump of network traffic, use --pid or --process to filter specific processes.
   ios apps [--system]                                                Retrieves a list of installed applications. --system prints out preinstalled system apps.
   ios launch <bundleID>                                              Launch app with the bundleID on the device. Get your bundle ID from the apps command.
   ios kill <bundleID> [options]                                      Kill app with the bundleID on the device.
   ios runtest <bundleID>                                             Run a XCUITest.
   ios runwda [--bundleid=<bundleid>] [--testrunnerbundleid=<testbundleid>] [--xctestconfig=<xctestconfig>] [--arg=<a>]... [--env=<e>]...[options]  runs WebDriverAgents
   >                                                                  specify runtime args and env vars like --env ENV_1=something --env ENV_2=else  and --arg ARG1 --arg ARG2
   ios ax [options]                                                   Access accessibility inspector features.
   ios debug [--stop-at-entry] <app_path>                             Start debug with lldb
   ios reboot [options]                                               Reboot the given device
   ios -h | --help                                                    Prints this screen.
   ios --version | version [options]                                  Prints the version


for i, c := range data {
    // your code 
}

#golang