It would help if the submitter explained what this was about. What's so offensive about calling 'MessageBox WinApi without using the Winim library'? Or how it is a weapon: is it going to help Ukraine drive Russia back or help Putin achieve his dreams of a Greater Russia?
"Offensive <Language>" is about using a programming language for red teams. Stuff like writing malware, privilege escalation, antivirus evasion, etc... The "weaponization" here is about using the language for malicious apps.
There's nothing offensive about the MessageBox example, it's mostly showing how to use Win32 APIs in various ways, which is going to be necessary for a lot of the more malicious stuff, such as calling VirtualAllocEx to allocate executable code[1].
I think @tgv was A) trying to be funny/sarcastic, and B) using 2 different definitions of "offensive" (of which the dictionary has a few, actually [0])..all to make the point that the meaning of "offensive nim" is somewhat ambiguous without more context.
EDIT: @tgv might have been more understood himself had he said "title should be changed to 'Offensive (Red Team) Nim'" or something along those lines.
I was not trying to be funny. I just didn't understand it, and had no idea this was a regular term. There are two common meanings for offensive, and one of them matches "weaponize", but none of them fitted the README. I did try to avoid sounding condescending or negative by giving light-hearted examples in the only context I knew for those words.
nim truly deserves more love,it is my lang to pick up this year,safe c++ with python syntax,great combination to me,and it is also mature,cross platform,production ready.
I think it's a pretty nice prog.lang (PL). You may be very happy. Though nothing is perfect, there is much to recommend it. By now I've written over 150 command-line tools with https://github.com/c-blake/cligen . A few are at https://github.com/c-blake/bu or https://github.com/c-blake/nio { screw 1970s COBOL-esque SQL ;-) } or in their own repos. I use quite a few every day..(EDIT: some even dozens of times per day - "production" is more an aspect of code than a PL itself - e.g., is poorly tested Python code "production").
If it helps, I like to use the "mob branch" [0] of TinyCC/tcc [1] for really fast builds in debugging mode, but this may only work if you toss `@if tcc: mm:markAndSweep @end` or similar in your nim.cfg. Then I have a little `@if r: ...` so I can say `nim c -d:r foo` for a release build with gcc/whatever.
Thanks. Just a fraction published as I try to motivate/document/clean up before doing so. I kind of live at the Zsh prompt and tend to fill gaps as I find them & iterate on that.
Also, if you think of an idea for more, please feel free to raise an issue - maybe it's already done somewhere. Or even better, use it as an excuse to learn Nim and file a PR or even better do your own repo. :)
I had played with it a bit, and used it as my Advent of Code language this year. I really adore the language, it's been my go-to language for hobby projects lately. I wouldn't say it's quite production ready, but for personal projects I think it's great.
- Nim is case-agnostic. Tokens ignore cases and underscore so foo_bar == foobar == fooBar. I personally find this enjoyable for my personal projects, but it remains a contentious subject.
- Parallel support is pretty buggy. I've had loads of bizarre issues related to parallelism on the current version (1.6.10). However, from what I've tested in the release candidate, version 2.0.0 seems to have fixed a lot of these issues.
- The official documentation is really good, but if you don't find something there, its hard to find it anywhere (details regarding its Javascript target remain pretty sparse, for example). All new languages will suffer from this though, and I don't think its severe enough to mark is as "not production ready" by itself, but it's worth noting.
> Nim is case-agnostic. Tokens ignore cases and underscore so foo_bar == foobar == fooBar.
I have yet to be conviced it is a negative - or that the potential cons outway the potential pros, and I'm steadfastly stuck on this hill for now. Thanks for the comment.
Not sure what program initially seemed malicious to the makers of anti-virus software, but work like this combined with laziness/unresponsiveness of AV software makers Re: fixing false positives can create trouble for almost any small userbase programming language. Many mentions with Nim can be seen at https://forum.nim-lang.org/search?q=av (and probably other queries as well). I think at some point the binary executable for the Nim compiler itself was flagged. :-(
Well, type safety is not only relevant for security related things. It plain and simply makes working with a language much more pleasant and less error prone. Less time wasted debugging code etc.
I'll add that beyond strictly "offensive" tooling, Nim has more or less replaced Python in my toolkit for things like reimplementing custom encryption routines during an engagement.
Static types are a huge benefit in staying sane, IMO, especially when doing bit/structure twiddling. Sure, there are ways of accomplishing this is dynamic languages, but Nim is both fast and fun to use.
I would say the value of distinction is related to how many things you distinguish..Re-stated, the likelihood you mix things up (and thus the value of a checker) depends upon how many things.
Perhaps nigh tautological, but a rapid corollary of this is that if everything is a string/line in a file, the distinction is less valuable than if you have many kinds of CPU register (say). In fact, there is even https://en.wikipedia.org/wiki/Typed_assembly_language .
27 comments
[ 4.9 ms ] story [ 59.1 ms ] threadThere's nothing offensive about the MessageBox example, it's mostly showing how to use Win32 APIs in various ways, which is going to be necessary for a lot of the more malicious stuff, such as calling VirtualAllocEx to allocate executable code[1].
I doubt this will help either Russia nor Ukraine.
[0]: https://github.com/trickster0/OffensiveRust
[1]: https://github.com/byt3bl33d3r/OffensiveNim/blob/master/src/...
EDIT: @tgv might have been more understood himself had he said "title should be changed to 'Offensive (Red Team) Nim'" or something along those lines.
[0] https://www.dictionary.com/browse/offensive
EDIT: FWIW I think in this case the origin is just "opposite of 'defensive'" as in "offense & defense" in sports..red & blue teams, etc.
Given the compilation step to C allows nice FFI and using all kinds of compilers
If it helps, I like to use the "mob branch" [0] of TinyCC/tcc [1] for really fast builds in debugging mode, but this may only work if you toss `@if tcc: mm:markAndSweep @end` or similar in your nim.cfg. Then I have a little `@if r: ...` so I can say `nim c -d:r foo` for a release build with gcc/whatever.
[0] https://repo.or.cz/w/tinycc.git
[1] https://en.wikipedia.org/wiki/Tiny_C_Compiler
That's quite an impressive amount of cmdline tools.
Also, if you think of an idea for more, please feel free to raise an issue - maybe it's already done somewhere. Or even better, use it as an excuse to learn Nim and file a PR or even better do your own repo. :)
Would you mind elaborating why.
- Nim is case-agnostic. Tokens ignore cases and underscore so foo_bar == foobar == fooBar. I personally find this enjoyable for my personal projects, but it remains a contentious subject.
- Parallel support is pretty buggy. I've had loads of bizarre issues related to parallelism on the current version (1.6.10). However, from what I've tested in the release candidate, version 2.0.0 seems to have fixed a lot of these issues.
- The official documentation is really good, but if you don't find something there, its hard to find it anywhere (details regarding its Javascript target remain pretty sparse, for example). All new languages will suffer from this though, and I don't think its severe enough to mark is as "not production ready" by itself, but it's worth noting.
I have yet to be conviced it is a negative - or that the potential cons outway the potential pros, and I'm steadfastly stuck on this hill for now. Thanks for the comment.
Want to know every library on GitHub that uses "mySpecialNimConst" in it's code?
Enjoy the hunt
Static types are a huge benefit in staying sane, IMO, especially when doing bit/structure twiddling. Sure, there are ways of accomplishing this is dynamic languages, but Nim is both fast and fun to use.
Perhaps nigh tautological, but a rapid corollary of this is that if everything is a string/line in a file, the distinction is less valuable than if you have many kinds of CPU register (say). In fact, there is even https://en.wikipedia.org/wiki/Typed_assembly_language .
Does anyone know of a working implementation you can play with today?