In the "src" directory, the file Readme.txt contains instructions on how to build VeraCrypt for Windows, Linux and MacOSX.
For Windows, you will need Microsoft Visual C++ 2008 (later version should work) and also Microsoft Visual C++ 1.52 (this is a legacy compiler needed for the bootloader build. it is available for MSDN subscribers).
Moreover, the device driver of VeraCrypt must be signed by a valid code signing certificate in order for it to be loaded by Windows. If you don't have such certificate, then you will need to run Windows on testing mode.
Lastly, the creation of the installer is done by calling the script "sign.bat" that is present in the "Signing" directory : it is responsible for packaging all the components and invoking the code signing tool in order to sign all the component
and the final setup.

Thanks. I tried installing and received "ld: symbol(s) not found for architecture i386" and "error: linker command failed with exit code 1 (use -v to see invocation)". How do I identify the source of the problem?

What version of Xcode are you using and on which system are you building? You must check that you have MacOSX SDK and not only iOS SDK.
Did you install command line tools of Xcode?

If your build environment is setup correctly and all dependencies are present (nasm, pkg-config, OSXFUSE), then identify the version of MacOSX SDK present with your Xcode (for example 10.8) and then issue the following commands (/usr/src/wxWidgets should contain
the wxWidgets 3 latest sources):

Actually the build is successful! There are only some warnings and the VeraCrypt binary is created at the end.
The last error you are seeing is due to the fact that the Makefile performs the code signing of the VeraCrypt bundle using my Developer ID certificate which you don't have of course.

You can use the VeraCrypt bundle that is compiled on your machine if the signature verification feature of MacOSX is disabled (called Gatekeeper, here is a link that explains it :
http://support.apple.com/kb/ht5290).

If you have your own Apple Developer ID certificate, then you can modify the file
src/Main/Main.make at line 167 and 169 in order to specify the label of your Developer ID.

Ah, yes. Thank You. However, there is a new issue. When attempting to create a VeraCrypt volume, I receive about
fuse and "" being an invalid mount point. Do You have any idea what would be causing this? The volume creation does not appear to be successful apart from reserving the space.

I was able to reproduce your issue only when the SDK used for build is set to 10.9. If you set the SDK to 10.8, the error doesn't appear.
Thus, the issue appears to be linked to OSXFUSE library that behaves incorrectly if called from a program built using 10.9 SDK.

Honestly, I don't understand why the same C code triggers different behaviors depending on the SDK used. A possibility is that the 10.9 SDK changed binary alignment for kernel calls and the OSXFUSE kernel extension is compiled using 10.8 SDK or less.

Anyway, this is something that has to be investigated on the side of OSXFUSE. As for VeraCrypt, you can solve the issue by setting the SDK to 10.8 :

export VC_OSX_TARGET=10.8

I have put a script in src/Build called build_veracrypt_macosx.sh that simplifies the build process. The only requirement is to put the wxWidgets 3.0.2 sources at the same place as your checkout: for example, if the path to the src directory
is "/Users/xxx/Projects/VeraCrypt/src", then wxWidgets sources should be in "/Users/xxx/Projects/wxWidgets-3.0.2"
In this script, you can modify the value of the SDK used for the build.

For the record, we use SDK 10.6 for the official VeraCrypt MacOSX build in order to ensure the maximum compatibility across all version of MacOSX. That's why the issue you reported doesn't appear with the official VeraCrypt binary.

I gotta admit at the level of support you provided one user while still enhancing this product is world class.
I made the switch to VeraCrypt from TC a week ago. No issues installing it on Yosemite. Works pretty much like TC.
Well done, looking forward to future builds!

I agree with cyberfed's comment, thanks. I receive a different error when I use the 10.8 SDK. (I was using 10.9 because I am on 10.9 and thought it was the logical choice.) Searching the web for this new error message leads to
https://github.com/osxfuse/osxfuse/issues/119, suggesting OSXFuse is not the best choice for the situation. I will try the new script in a moment and see what happens.

First, the script build_veracrypt_macosx.sh uses the SDK 10.6 which you don't have. You should modify it to put the 10.8 version instead.

Second, it seems you are not using the standard shell the comes with Apple OSX Terminal application. I suspect that you have installed some software like Homebrew, MacPorts or other nix-like tools on your machine and this generates errors in the scripts. As
you can see in the error log you posted, the paths seem truncated for some weird reason. Also check that the line ending the script file was not modified during it transfer.

The script is confirmed to work on standard OSX machines with Xcode. As a matter of policy, we only use native development environment on every platform in order to ensure the maximum reliability and reproducibility of the build process and its outputs.

Concerning OSXFuse, for now we have no other choices other than using it. Let's hope that the upcoming 3.0 version will bring more stability and reliability.

Well, MacFUSE project has stopped many years ago and is no longer maintained. OSXFuse started as a fork of MacFUSE. On some forums, people distribute some modified versions of MacFUSE that apparently solve some issues but this can't be considered as official
releases. Maybe OSXFuse developer can incorporate some ideas from what others have modified in MacFUSE.

In the "src" directory, the file Readme.txt contains instructions on how to build VeraCrypt for Windows, Linux and MacOSX.

Hey there,

I just wanted to say thank you for all your work! I just successfully compiled Veracrypt on my ARM based Chromebook (via crouton chroot) using the instructions taken from the Readme.txt. I haven't compiled any bigger piece of software in
years, but now I had to - and it worked flawlessly! There were no Truecrypt binaries for current ARM based Linux systems anywhere, which is why I was searching, came across Veracrypt and gave it a try.

One hint for everbody who might want to use Veracrypt on a similar setup: In order for it to work you need to ensure that in the Veracrypt GUI you select "Settings -> Preferences -> System Integraion -> Do not use kernel cryptographic services",
as otherwise mounting a device will not work (probably an incompatibility with the Chrome OS Linux kernel or something). However, once that setting has been changed, everything works like a charm!

Thank you very much and please keep up the good work! From now on I will try to find the time and periodically compile upcoming veracrypt versions on my ARM Chromebook and report in case anything breaks the toolchain. So far everything works exactly like explained
in the guide for Linux.

In order for it to work you need to ensure that in the Veracrypt GUI you select "Settings -> Preferences -> System Integraion -> Do not use kernel cryptographic services", as otherwise mounting a device will not work (probably
an incompatibility with the Chrome OS Linux kernel or something). However, once that setting has been changed, everything works like a charm!

Just a word of caution: Crypto stuff is different than any other program. "Everything works" is a necessary but insufficient condition to declare the program "ready to go". You just selected different crypto primitives in your execution
path which, contrary to major OS kernel/framework services, have not been security-audited to the same assurance level. Since Truecrypt's (and VeraCrypt's) crypto routines have never been audited by external experts in the field, I would be cautious.

Are you willing to publish the binaries resulting from your build? I think it could be interesting for other users of ARM Linux and I can link to them or host them on the contrib part of VeraCrypt on Sourceforge.

Concerning the failure to work with kernel cryptographic service, it could come from the lack the
dm-crypt kernel support in Chrome OS. When this option is checked (this is the default), VeraCrypt uses Device Mapper kernel module (dm-crypt through a call to dmsetup) to load volumes. If dm-crypt module is missing, you'll have an error (we
try in the code to load it manually through modprobe but it won't help if it doesn't exist).

Can you please check if the dm-crypt is available or not on Chrome OS? I found some resources indicating that it is not present but I didn't find any official statement with this regard.

Concerning
ninveh statement, I agree that one must be cautious before using unreliable cryptographic libraries. Nevertheless, the cryptographic primitives present on TrueCrypt and VeraCrypt have been checked by many experts and professionals and they are based on
renowned public domain implementations. As one may expect, I personally spent a great deal of time checking those primitives and the overall implementations that uses them and I didn't find anything suspicious or non-conformant (apart from a bug that I corrected
in the Serpent implementation of TrueCrypt that luckily had no effect on real world situations).

An audit is always welcomed and I'm open to any initiative on this side for VeraCrypt. On practice, little encryption products are really independently audited and even if they are audited there are always clouds about who has performed the audit, what context
and the people behind such initiatives. Open source brings more transparency to any audit process of encryption solutions but sometimes this transparency can be hijacked by a certain elite who wants to impose itself as the custodians of cryptography or security.
On these uncertain days, it is important to build a real community of security aware users and developers in order to bring a more democratic approach to encryption adoption and development.

Idrassi, responding to your response to my statement, please note the following

Common security issues in software are not with the encryption algorithms/primitives but with their implementation.
I beg to differ on the actual "checking by many experts" - I researched this in the past and could not find any reference to a crypto audit (there were 2 bodies in the far past (one German and one French) that reviewed the general code, but as far
as the crypto, they only looked at the volume headers. They did not delve into the crypto implementation). There was a fair amount on discussion on the Schneier blog in 2013 on this, and Kenn White and Matt Green et al, together with Schneier on the advisory
board, established some kind of a foundation to contract out the audit of the TC code, but only got as far as the general code flow review (what they called Phase A). Nobody looked at the crypto part because right about the time they set up the crypto audit
process, the TC foundation announced its demise, and the audit process died with it.

Although open source is almost mandatory for having trust in crypto code, it does not guarantee that many eyes will look it it to find bugs. The most talked about crypto fail last year was related to openSSL, which certainly had many more followers and
major corporations interests than in TC, but even there evidently nobody looked at the code. Another example from 6 years ago - the weak Debian keys due to removing 2 lines in the code by Debian developers who thought to optimize a specific section. No malice
there - they just could not comprehend the danger in messing with crypto code.http://en.wikinews.org/wiki/Predictable_random_number_generator_discovered_in_the_Debian_version_of_OpenSSL

I agree with all what you said,
ninveh. But, what is the point?
We have to stop using TrueCrypt/VeraCrypt/DiskCryptor and soon CipherShed?

We all on these projects do our best to provide state of the art encryption solutions. Obviously, mistakes can be made but we are all very careful about every single line we write since our work can have a large impact on many people working on dangerous situations
or protecting sensitive information.

Should we just stop using encryption and wait for "approved" solutions?

Anyway, I don't want this thread to deviate from its original purpose although the subject of implementation trust is very important. Maybe we should open a new discussion.

I re-iterate here my request for sharing the Chrome OS binary and my question about the availability of dm-crypt in this OS.

I just wanted to point out to the original poster that he/she now goes through a different code path, outside the tried-and-true WIN/MAC/Linux core crypto primitives that everybody else have been using for some years in TC/VC, and he/she should be cautious.
Not necessarily to stop using VC on his/her unique system, but just to be aware of the possible implication. I myself would be confident with running VC on a Win machine, for example, but not on an ARM-based system.

And I totally agree that this thread is not the right place to continue with my comments.

I re-iterate here my request for sharing the Chrome OS binary and my question about the availability of dm-crypt in this OS.

Hi again,

Interesting discussion. First of all, I would to like to say that my main objective was to be able to open some of my old TrueCrypt containers that I have created years ago via my Chromebook and not depend on anybody else's Windows PC or similar. Therefore,
rock solid security is not what I had in mind, at least not right now. However, I understand that many people take this very seriously, and since some people depend on
real, uncompromisable security, they want to be sure they can trust in the implementation of the program they are using. In this case it was just out of technical interest and basically due to practical reasons.

I have uploaded the whole build directory after tar'zipping it. As I don't use Dropbox, I just used the first random share hoster I could find. Just let me know in case this one doesn't work or there are any other issues with it. The binaries can be found in
the "Main" directory after unzipping the tarball.

Very cool. I just checked out the tweet as well. There might be quite some people who might find this useful, as there've been some more ARM based Chromebooks coming out over the last couple of months by several manufacturers. There's also some people
who run pure Linux on these systems as dual boot options. In any case, a working implementation of Veracrypt is filling a gap here.

I tried to find out whether the Chrome OS kernel supports dm-crypt and it seems it does, however it seems it cannot be accessed properly from a chroot environment. I came across one older posting mentioning this on the crouton discussing board.

A couple of hours ago I was finally accessing an external USB drive with full drive encryption that I had encrypted using TrueCrypt over a year ago - from my Chromebook. Very happy. Hint for people who want to do the same: as the drive is encrypted, it won't
appear in the list of mounted (accessible) drives in ChromeOS or any file explorer - therefore you'll have to check via "dmesg" what /dev device the drive was assigned. In my case it was /dev/sda1. Just enter that device directly into "Volume"
field in the Veracrypt UI and it can be mounted.

If you have time, is it possible to build a console version of VeraCrypt? I think this could make it usable by more users.

Hi!

I just tried... however, as I need to compile it with:

make NOGUI=1 WXSTATIC=1

the WXSTATIC=1 part is giving me problems (I don't have the required sources). I compiled my working version which I uploaded yesterday with just "make".

I even tried only doing "make NOGUI=1" but that wouldn't work either.

As I don't have the sources (no /usr/src/wxWidgets or /usr/local/src/wxWidgets directory) and there don't seem to be any packages for it, I can also not perform the "make WXSTATIC=1 WX_ROOT=/usr/src/wxWidgets wxbuild" part.

I would need to get the wxWidgets source files in some other way, I think. I checked the wxWidgets website as well, which has a repository for deb packages; I added that one, but trying to view the repository contents ends in an error as they don't have the
target ARM in their repo. I could check and see if I could get those packages or the source package in a different way, however I don't know if the sources contain any assembly code that might be Intel-only. There should obviously be some way (especially since
the pre-compiled shared libs are available and I was able to install them from the Ubuntu repository), but I suspect that might all lead in dependency-hell and dozens of failed compiling sessions...

Sorry for my apparent imcompetence (I've got no real programming background and was just compiling lots of stuff around 15 years ago as a *BSD/Solaris user but haven't spent much time doing these things after that). If anyone has any hints on how to solve this,
I'll give it another try though!

To my knowledge, wxWidgets code doesn't contain any assembly language so it should be possible to download the source and compile it yourself.
For example, if you extract the source to /home/user, you will get a folder called wxWidgets-3.0.2. From here, you can type:

export WX_ROOT=/home/user/wxWidgets-3.0.2

export WX_BUILD_DIR=/home/user/wxBuild

make WXSTATIC=1 NOGUI=1 wxbuild

make WXSTATIC=1 NOGUI=1 clean

make WXSTATIC=1 NOGUI=1

This should give you a console only binary that is statically linked to wxWidgets.
Actually, you can do the same for the GUI version of VeraCrypt in order to link also statically against wxWidgets. This will make the generated binary more portable.

I also attempted to compile a statically linked build of the GUI-based version, however to my surprise that brought further issues, as make was complaining that I don't have some gtk+ dev files on my machine. I'm sure I could fix that though, in case anyone
explicitly requests a statically linked GUI version of this.

The umask of the files inside the uploaded tarball might look a bit messed up since I did a chmod -R 777 on its root directory for reasons not worth mentioning.

I hope somebody will find this useful. Long live the arm architecture!

I have update the
ARM archive on Sourceforge with the new binary. Thanks a lot!

Thank you also for your effort on the static build of the GUI version. I agree that it is not very important at this stage. This is the first ARM build of VeraCrypt and I hope there will be more feedback about it.

The new Raspberry Pi 2 is now armv7 based and therefore should be able to run the precompiled statically linked build on the default Linux distro that comes with it. Anyone who already bought one and can test it? I'm planning on getting one myself and
then putting NetBSD on it... I'll attempt another build with that one as well (should otherwise be possible to use the Linux binary compatibility though)

I have been unable to build VeraCrypt under OS X 10.7.5. I am trying to build a no gui version. I have sources at the same level for wxWidgets and VeraCrypt. I have pkg-config installed and Xcode and command line tools installed and I am using 10.6 SDK.

First, it would have been better to put a link towards a file containing the build logs instead of copying everything here (you could use pastbin for example). This kind of verbose output makes the thread unnecessary long and only few lines are really interesting.

Concerning your issue, the error indicates that the compiler can't find the definition of the standard function wcsdup which is not normal. Moreover, wxWidgets have been compiled successfully so this function exists.

What's your version of Xcode?
Do you have custom software like Homebrew or MacPorts?
Can you check that the directory /Developer/SDKs/MacOSX10.6.sdk exists? More generally, what's the content of
/Developer/SDKs

I think it is just caused by the fact that we can't find the correct SDK to use.

Thanks for your reply I've edited the previous post. I am using Xcode 4.6.3 Build version 4H1503 and I do not use Homebrew or MacPorts. I have '/Developer/SDKs/MacOSX10.6.sdk' and '/Developer/SDKs/MacOSX10.7.sdk' and they are both populated. I have compiled
programs with the SDK's in the past and in the present.

Lines that seem strange to me are;
'/usr/bin/ranlib: file: /Users/jimmy/Temp/VeraCrypt/wxBuild/lib/libwx_baseu-3.0.a(baselib_extended.o) has no symbols'
'ranlib: file: /Users/jimmy/Temp/VeraCrypt/wxBuild/lib/libwx_baseu-3.0.a(baselib_extended.o) has no symbols'

which are prior to 'Cleaning Platform' and of course all of the 'error: <function name> was not declared in this scope' messages.

I tried a build using the 10.7 SDK and it made it through up to trying to link the wxWidgets library. If I'm interpreting the message correctly it appears that a wxWidgets (i386) library was not built or whatever was built or attempted to be built is unrecognizable.

'Linking VeraCrypt'
'ld: warning: ignoring file /Users/jimmy/Temp/VeraCrypt/wxBuild/lib/libwx_baseu-3.0.a, file was built for archive which is not the architecture being linked (i386): /Users/jimmy/Temp/VeraCrypt/wxBuild/lib/libwx_baseu-3.0.a'

I completely missed the fact that you are building a NOGUI version as cited in your first message.
As you can see in the official build script for MacOSX, this is not supported.
This is caused by issues in the build of a console only version of wxWidgets under MacOSX (no problem on this side under Linux) which are due to dependencies issues on MacOSX that makes it impossible to remove GUI libraries from the build.

The objective a the NOGUI build is to have a smaller binary with minimal dependencies. On MacOSX, this is not possible and so the alternative is to use the --text switch on the normal binary. In this case, you can use the VeraCrypt binary outside the MacOSX
bundle like a normal console binary.

Firstly, thanks to all of you and your efforts in creating and maintaining VeraCrypt. The information you have given is completely missing from the documentation (Readme.txt) and in fact the documentation indicates that it is possible under the 'Instructions
for Building VeraCrypt for Linux and Mac OS X:'. In that section it states that the 'NOGUI' parameter can be used to build a console-only executable. The specific make command is sited thereafter.

If you are indeed 100% sure that the developers have not been able to code for the creation of a 'NOGUI' version under OS X then I would suggest you adjust the documentation to indicate this so it does not mislead people and waste time for others in the future.
Under the 'Mac OS X specifics:' section would be a good place to add that the 'NOGUI' option is unsupported and that the --text switch can be used as an alternative.

On the development side, TrueCrypt never provided a NOGUI binary for MacOSX and at the beginning of the VeraCrypt project I tried to build such version but I failed because of the dependencies issues I cited above. That's why I abandoned such effort but any
help to make this work is welcomed.

My build environment consisted of a stock Raspbian Wheezy system on which a dist-upgrade had been performed. All of Haggsters instructions where followed save those that excluded GTK related options. My dev package list is as follows:

Hi, I finally got around to compile an updated ARM build, based on the current Veracrypt version (1.19).

I've seen that there are some other people now who seem to have ARM builds now as well (mostly, or all, built on RasPi's), but since they all seem to have been built with NOGUI, I thought I'd contribute this updated build - with GUI - anyway, in order to fill
that gap: