How to Decompile an unknown packed .exe - decompiling

I'm new to decompiling, so I'm sorry if I sound like an idiot.
Using Process Explorer I found out that the .exe I want to decompile is packed, and via PEiD it says "Nothing found *" . Due to it being packed, I am clueless on how to proceed. Any suggestions?

It is recommended to ask questions about Reverse Engineering in its suitable Stack Excahnge community.
There are already existing questions in SE.RE that might help you:
Unpacking binaries in a generic way
Unpacking binary statically
In a personal note, I'd suggest you to stop using PEiD since it is not maintaned for years. Check out Detect It Easy.

Related

How to compile CGAL code into a shared library?

This is a pretty rookie question, but unfortunately I'm not really familiar with cmake or CGAL. I just can't figure out how to configure cmake to generate a shared library from my source code. I looked through some docs and some pages on github, but I don't seem to get anywehere.
I would be really grateful if someone could point me to some documentation, or provide an example CMakeLists.txt or something (to be honest I'm completely lost here).
I need the .so-s for a python binding for some functionality of the 2D arrangements package.
The CGAL Manual has copious information you can use to get you started. Here you'll find information for building/installing CGAL itself.
If you already have CGAL built/installed on your system, there are some examples to show how to use it in your own CMake project. Check out their Github wiki, or for even more info, Sections 14 and 15 of their Installation Manual.
You mention python bindings, so if your looking to use something like SWIG, I suggest taking a look here.

NSIS - Compile with opcode re arranged to prevent access to source code

I am trying to reduce and make as difficult as possible the ability to access my source code after being compiled by NSIS. I have read that the only way to reduce the chance of unzipping is to modify the order of the opcodes in the Source\fileform.h from the source code and then Compile the new version.
This is a bit over my head. I was wondering if anyone has done this before and willing to post one they have done. (Or create one for me?)
Main reason for this is I have info that I encrypt using blow-fish within NSIS and do not want the chance oFf someone finding out what the encryption keys are. (Used for licencing the software) I understand noting is fool proof, but just want it as difficult as possible.
I know its asking a lot, but could really this.
Thanks!
I don't believe there are any publicly available modified builds like that. And if there were and it got popular, the decompilers would just add support for it.
I have a complete step-by-step guide to building NSIS here.
If you know C/C++, Delphi or C# you could build your own private NSIS plug-in that handles the encryption details.
No matter what you do, somebody who knows how to use a debugger can easily set a breakpoint on the blow-fish plug-in and view your key. The only way around that is a custom plug-in or an external application that handles the cryptography internally...

Is it OK to modify the default location for Python-3.6.0.exe to just the C drive?

I am a 65 year old "newbie" and generally use default options when downloading. Python.org wants to download to an obscure directory such as
C:\Users\Facdev\AppData\Local\Programs\Python\Python36-32".
Is there anything wrong with downloading instead to "C:"?
This should not pose a problem, as long as the directory is specified correctly in you PATH.
It is OK to modify the location where you will download and install Python. However, I would advise against doing so if you are unfamiliar with how system environment variables and PATH locations work in Windows.
Why does it matter?
Once you have the python executable (in your case Python-3.6.0.exe) on your system, your computer needs to know where it is in order to execute it! If you place the executable in a location like the main directory on the C: drive your computer does not care. Your computer also does not care if the executable is deep down in the AppData\ directory.
By changing the default behavior you run a risk when troubleshooting unexpected behavior that instructions will not be written for your situation. This is OK as long as you understand what you will need to change in order to apply the troubleshooting techniques listed on documentation, blog posts, and forums.
Because of those factors and this being a new process for you, I recommend sticking to the default. You can change the location later, once you understand what doing so means. Learning to program can be frustrating and trying to grasp managing the software environment only adds to the frustration. Tackle that issue later.
Good luck on your new adventure! I hope you learn to enjoy writing your own programs in python!

complie a exploit that has a makefile

So it is 5:12am and I have been trying to figure this out for hours. I am a little new to the subject so please forgive the noob.
I download this exploit from http://www.exploit-db.com/exploits/9301/ .. The problem is the program comes with two .c files and 2 .h files along with a makefile. Could anyone shed some light on how to complie this. I can't seem to find the information I am looking for.
BTW this is for a security course I am taking online.
Thanks
Type make. If you don't have make installed, you will need to install it (and in that case it is very likely you will also need to install a C compiler and its dependencies).

Haskell, Hackage, GHC and productivity. How to solve a real example?

I don't know the best way to solve a simple (probably) problems (hackage related).
I asked for help about it (http://stackoverflow.com/questions/12841599/haskell-hackage-ghc-and-productivity-what-to-do) but I knew not explain well.
Today, I'm with a this kin problem.
The concrete problem isn't relevant, but is it:
`Write a function that, given a string, remove diacritics.`
Example:
`simpleWord "Cigüeñal" <-> "Ciguenal"
The correct way (I think) is to use the standard Unicode normalization. In some languages/frameworks (.Net, PHP, Python, ...) exist some related function.
In Haskell, thanks to hackage community exist too:
`Text.Unicode.Normalization.normalize`
But, I couldn't install with (eg) ghc-7.4 but compact-string (that depends of) fail.
A fix for compact-string exists (compact-string-fix) then: can't I use cabal to install (directly)?, should I download and patch it?, should I look for another alternative to function about?
I explained a concrete real case (simple or complex, don't care), the question (that I ask help for) is how can, a novice haskeller, know the best way to select correct libraries, ghc correct (balanced) version, without hit a wall.
I'm really lost about it.
Really, thank you very much for any suggestion.
Best regards.
The documentation for compact-string says, "This package is obsolete. Use text instead.".
The documentation for text says, "To use an extended and very rich family of functions for working with Unicode text (including normalization, regular expressions, non-standard encodings, text breaking, and locales), see the text-icu package.".
The documentation for text-icu shows that it successfully builds on GHC 7.4 and has support for Unicode normalization.
Here's the general process I follow when deciding which packages to use. First, I try to identify multiple packages that meet my needs. Then I look more closely at each package to try to determine which ones are the best for me, according to the criteria listed below.
It's usually better to use packages that are currently maintained. To determine if a package is currently maintained, I check the "Upload date" link on the package description page. (Of course, there are some old tried-and-true packages that haven't been modified in ages because they don't need modification.)
It's usually better to use packages that are mature, so I check the version number on the package description page. A package with a version number of 7.3.5 is probably more mature than a version 0.1 package.
It's usually better to use packages that are well documented. Sometimes there's a nice example of how to use the package in the Haddock documentation (yay!). I'll also check the "Home page" link on the package description page, because often there will be more documentation there.
It's usually better to use packages that are popular, because any problems will probably be addressed quickly, and other users can answer questions. I'll usually do a Google search and see whch packages are mentioned most often on Haskell mailing lists and StackOverflow.
It's usually better to use packages that don't require a lot of packages I don't already have, so I check the "Dependencies" section on the package description page.
I tend to follow this procedure when choosing a package for any programming language, not just Haskell.

Resources