I wonder if is possible to have only precompiled modules or some sort of MoarVM bytecode.
The idea is to protect the source code at some grade - at least i don't want to be in plain text
Not at the moment. But the design of how CompUnit repositories work, makes that entirely possible. It's just that nobody has been willing to put in the work to make that happen. And it is on my (very long) todo list.
Apart from protecting source code (which may actually be a little more futile when the RakuAST branch lands), I was more thinking of the situation of running Raku on a very small processor with little memory (think RaspBerry and the like), which would make it nice if it would be able to load (binary) modules on demand over the network (without the source).
Related
Is there a Plug-and-play Common Lisp/Scheme implementation?
By Plug-and-play I mean an implementation with an IDE that doesn't require you to play chords with a pianist dexterity(so not Emacs), where you can run a program by pressing a button not writing commands in a console, with modern libraries and that is portable.
Racket supports all the features above EXCEPT portability. I wrote a program in Racket that I couldn't send to friends because it wouldn't run on other computers. I want to make programs that I can send as easily as a Java programmer sends a Jar file and you can run it with double-click.
I also don't like how Clojure looks.
So the big question: if someone doesn't know programming, can he learn LISP using this implementation as easy as someone who would pick Java or C#?
I think you are mixing a lot of different requirements in your description:
If you need something that compiles to a binary executable file, you can use a bunch of CL implementations that compiles to an executable file. You can even use https://common-lisp.net/project/armedbear/ that runs on JVM.
If you need something easy to start with, with editor and runtime embedded, you can use http://www.lispworks.com or things like https://common-lisp.net/project/lispbox/.
But it seems that you are also talking about the language. Well, the syntax is only one part of the language, don't evaluate a language just taking into account its syntax.
Finally, I don't believe that it is easy to start working with Java or C#. You may think that these IDEs make life easier, but in the reality, it takes time to install them, solve dependencies and really learn how to be productive with them. Those IDEs end-up being much less flexible and usable than Emacs that you criticized. I have some experience teaching CL for students that after 1-2 months quickly started to be very productively why Emacs.
Well I think that this days is pretty easy to install common lisp and intall slime with quiclisp then you can have your environment quick and easy
take a look at this question
Setting the SLIME in emacs
and in quicklisp:
https://www.quicklisp.org/beta/#installation
also I recommend you to take a look at the roswell an intend to be a lisp installer and launcher for major environment that just work.
project on github in the wiki section they have an easy form of start emacs with roswell:
https://github.com/roswell/roswell/wiki
require you to play chords with a pianist dexterity(so not Emacs)
One can use emacs like notepad and use menus and buttons to do actions instead of key combinations, that although arbitrary, don't require much dexterity to reach. It is clear to someone that have used SLIME that you SLIME satisfies your requirements but are deadset against emacs. If so, give Allegro Common Lisp a try.
Racket supports all the features above EXCEPT portability. I wrote a program in Racket that I couldn't send to friends because it wouldn't run on other computers. I want to make programs that I can send as easily as a Java programmer sends a Jar file and you can run it with double-click.
In racket you can use raco exe will produce a Stand alone executable, so Racket will also do.
I'm fairly new to programming and wanted to start programming more efficiently. Try as I may I often find myself straying from the MVC model.
I was wondering are there any tips or methods in keeping your code organized when coding in xcode objc? To be more specific (I know you guys like that :) I want to
Be able to write libraries or self-containing code that can bring from one project to another
Share my code with others as open sourced projects
Prevent myself from writing messy code that does not follow proper structure
Use a high warning level. Build cleanly.
Remove all static analyzer issues.
Write some unit tests.
Keep the public interfaces small.
Specify your library's dependencies (e.g. minimum SDK versions and dependent libraries).
Compile against multiple/supported OS versions regularly.
Learn to create and manage static library targets. This is all you should need to support and reuse the library in another project (unless you drag external resources into the picture, which becomes a pain).
No global state (e.g. singletons, global variables).
Be precise about support in multithreaded contexts (more commonly, that concurrency shall be the client's responsibility).
Document your public interface (maybe your private one too…).
Define a precise and uniform error model.
You can never have enough error detection.
Set very high standards -- Build them for reuse as reference implementations.
Determine the granularity of the libraries early on. These should be very small and focused.
Consider using C or C++ implementations for your backend/core libraries (that stuff can be stripped).
Do establish and specify any prefixes for your library's objc classes and categories. Use good prefixes too.
Minimize visible dependencies (e.g. don't #import tons of frameworks which could be hidden).
Be sure it compiles without the client needing to add additional #imports.
Don't rely on clients putting things in specific places, or that resources will have specific names.
Be very conservative about memory consumption and execution costs.
No leaks.
No zombies.
No slow blocking operations on the main thread.
Don't publish something until it's been well tested, and has been stable for some time. Bugs break clients' code, then they are less likely to reuse your library if it keeps breaking their program.
Study, use, and learn from good libraries.
Ask somebody (ideally, who's more experienced than you) to review your code.
Do use/exercise the libraries wherever appropriate in your projects.
Fix bugs before adding features.
Don't let that scare you -- it can be really fun, and you can learn a lot in the process.
There are a number of ways you can reuse code:
Store the code in a common directory and include that directory in your projects. Simple, but can have versioning issues.
Create a separate project which builds a static iOS library and then create a framework. More complex to setup because it involves scripting to build the framework directory structure. But easy to use in other projects and can handle versioning and device/simulator combined libs.
Create a separate project which builds a static iOS library and then include this as a subproject in other projects. Avoids having to build frameworks and the results can be more optimised.
That's the basic 3, there are of course a number of variations on these and how you go about them. A lot of what you decide to do is going to come down to who you are going to do this for. For example I like sub projects for my own code, but for code I want to make available for others, I think frameworks are better. even if they are more work to create. Plus I can then wrap them up with docsets of the api documentation and upload the whole lot as a DMG to github for others to download.
I have developed a number of frameworks that I want to ship with my application. I don't want others to be able to use the frameworks, but i've seen utilities such as class-dump which can get the headers back easily.
My question is, how can I make my frameworks more secure? I know that they'll never be 100% secure, but are there some good general tips to follow?
Thanks!
In short, don't bother. The very nature of the Objective-C runtime is that there is significant metadata available.
The reality is that it would be exceedingly rare for someone to pick up your framework and try to embed/use it.
Note that code obfuscators don't really work very well; there is still quite a bit of metadata that must be exposed. You can go that route, but -- generally -- it makes debugging/crash analysis significantly more difficult without actually solving a real problem.
I see others have pointed you down the path of obfuscation (though I suspect that the answer of #define someSelector mmmrrrggglll wasn't really tested much).
Some specific points to consider as you go down this path (I'm sure I've missed many):
if you use KVO/KVC, make sure you obfuscate all those calls to addObserver:* and the like
if you are targeting Mac OS X, don't forget about Bindings, too!
Interface Builder's xib files will often contain references to instance variables and/or properties and/or methods. Don't forget about those!
Anything that uses runtime introspection will need obfuscation, too.
make sure you don't obfuscate anything that the system frameworks are dependent; wouldn't want to subclass NSView, say, and then obfuscate drawRect: or initWithFrame:.
In some cases, the Info.plist can refer to class names and entry points. Don't mess with those, either!
Also, make sure every use of #selector() is also properly obfuscated; nothing like setting up an NSTimer firing against a method that no longer exists.
Make sure your obfuscation plans also includes the engineering work necessary to create an un-obfuscator for crash logs.
You'll also want to consider how you are going to debug a production binary; assume your stack traces will be obfuscated. b mmmrrrggglll ftw!
If your framework has symbol exports control, make sure to obfuscate 'em, too! Keep in mind that the way symbols are created differs between architecture and compiler, in some cases.
You can use static libraries to link with your application instead of frameworks. However, if you want to ship frameworks, you can use code obsfucators to make your library more difficult to use.
EDIT:
This SO post has a pretty simple description of a basic obsfucation.
How can objective C classes be encrypted
There are products on the market that do this, but they are expensive.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Objective-C Code Obfuscation
I am trying to put together an iOS package that can be reused in multiple apps. I would like to be able to bundle it up for others to easily plug in and use, and I would like to obfuscate the code so that no one can read it.
What would you recommend between building a framework, a static library, or another solution to accomplish this and why?
If you're distributing for iOS, you have two options:
Distribute a precompiled binary and headers
Distribute the source
Since you're asking about hiding stuff, I don't think #2 is what you're looking for.
As for #1, the best you can do is just not tell 3rd party users about more stuff. They'll still be able to use the runtime to find methods and properties and instance variables, etc. If you're doing everything in C-land (ie, no Objective-C classes), then they can still use things like otool to dump symbols.
In short:
It's probably not worth trying to "obfuscate" your code. Just tell them about the stuff they need to know about, then give them a .a file and the headers they need.
A framework is the standard Cocoa approach to shared code. You can distribute a framework as a compiled code library and a collection of public headers without making any of the underlying Objective-C soure code visible. Of course, a dedicated hacker could still read the machine code, but this would be a big undertaking, and probably not worth the time they would have to spend on it.
If you are really concerned about sensitive code, you could consider an internet-based service, in which your library calls out to a remote server under your control to perform some business logic. This approach is quite a bit more involved, and does not offer as much flexibility for your customers.
I've just finished a library in Objective-C that I compiled as a Static Library for distribution.
I'd wanted to know what chances to get this decompiled are out there.
Do you know any software that can do this?
If so, how could I protect me better?
EDIT: My static lib is made for iPhone / ARM
I created an algorithm that depending on the some parameters of the app, it can run as demo or as full code. You init the object with X variables and unlock the full version. I was wondering if they'll be able to see this algorithm so they can create a key generator.
If it executes, it can be decompiled. Objective-C is particularly easy to decompile into readable code thanks to its dynamic features. If you want to make things a little bit harder, you could write most of your code in plain C and strip the executable — which of course has the tradeoff of making your application design harder to manage. But be honest with yourself: If somebody wants to crack your code, you are not going to be able to stop them. Crackers have practically unlimited amounts of time and enthusiasm and will actually be excited by any novel efforts you put in to stop them. Nobody has yet made uncrackable software, and the biggest corporations in the world have tried. You're not going to do better than them, especially if you need to ask about it on Stack Overflow.
Take the time that you would have put into thwarting decompilation and use it to make your product better — that will have a much better ROI.
It's not clear what you are trying to protect yourself from. Yes, it can be reverse engineered. The simplest tool is otool, part of the standard developer distribution:
otool -tV <library>
From that they run up to things like IDA Pro, which has iPhone support and is very nice for this kind of work. In between, I'm really surprised that I haven't seen a rework of otx for iPhone/ARM yet. I wouldn't be surprised to see one show up eventually. And of course there's gdb if you're trying to work out how things flow and what the data is at various points.
If you have more details about what you're trying to protect yourself from, there may be some targeted answers. Beyond that, read Chuck's comments.
ChanceGetsDecompiled = ExpectedGainFromBeingDecompiled / PopularityOfLibrary
Well if you REALLY want to know I would try decompiling it your self. You don't say if this is for PPC, Intel, or ARM which makes a difference. Here is a decompiler for Intel
i386 Decompiler
I don't know what you could do (I don't think there is much) to limit this. Code can always be reverse engineered. Be happy that your not using java or .net. Their decompilation is so nice.