Krave Beef Jerky Review

First off I have to say i was very excited to review this product, Krave Beef Jerky is right up my ally. I love meat, what can I say. I've tried not eating meat, it lasted about a week then I broke down and ate some delicious bacon. So when the wife (Aimee) came to me and said eat this meat and write a review for it I said "thank you." 

Krave jerky is awesome. They have a great variety of cool flavors that use all natural ingredients. I use to think that all jerky was dry and leathery strips of meat and that's how it was supposed to be. Man was I wrong, Krave Jerky is so moist and beautiful and tender. Oh how I wish there were more words in the dictionary, that I could think of at this moment, to explain the taste of this Jerky. It almost melts in your mouth, and you don't feel like you just ate something that was sitting in a vat of salt. Or something that was attached to a shoe at some point in time like some of the gas station Jerky I have had. The only time I have had something like this was when I have had home made jerky. But even then I have never had any with these flavors (Black Cherry Barbecue, Basil Citrus, Chili Lime, Garlic Chili Pepper, Lemon Garlic, Pineapple Orange, Grilled Sweet Teriyaki, and Sweet Chipotle) you can order them from KRAVE.

If you like jerky you will love this jerky, heck if you don't like jerky (like Aimee) you will more than likely love this jerky (like Aimee) it's just that good. 

Review by Cody Tate

Disclaimer: I was sent these products for free from KRAVE to review for my honest opinion. I only recommend products or services I use personally and believe will be good for my readers. Your opinions may vary from my opinions.

Read More

Defending Your E-Mails from Surveillance … Conveniently

With the recent and ongoing disclosures of what appear to be widespread Internet surveillance programs, the public is becoming increasingly aware of the privacy risks in sending plaintext E-mail.  Even connecting to one's E-mail service provider using a cryptographically secure protocol like HTTPS provides a false sense of security, because one cannot ensure the trust or privacy of any intermediary servers/connections used to route the message to its recipient.  As such, there are many excellent tutorials—and even entire web campaigns—that empower average users to protect their online communications via free tools like OpenPGP.

Since day one, Digital Operatives has employed strong cryptography to protect all of its internal E-mail communications.  This works extremely well, and, for all intents and purposes, is currently very secure.  There are some downsides, however.  The number one complaint about using public key cryptography to secure all E-mail communications is that there really isn't a good way to search through the bodies of the E-mails in your inbox (since the message bodies are encrypted, a simple search for a term like "cat" or "meeting" won't match any of the E-mails it otherwise should have).  In fact, the second bug ever reported for the popular EnigMail GPG plugin for the Thunderbird mail client was a feature request asking for the ability to search through encrypted E-mail bodies.  That bug was opened in 2003 … and it is still open today.

The trouble is that the decryption step is too computationally expensive to decrypt all of the message bodies on the fly during the search.  The alternative would be to temporarily decrypt the message bodies of new E-mails as they arrive and add them to a search index.  The trouble is that this invites a security vulnerability, since sensitive message data would therefore be included in the search index.

Given that over 90% of the E-mail in our inboxes at Digital Operatives is encrypted, we decided to scratch our own itch and develop a solution to this problem.  We took the second approach mentioned above: We incrementally build a search index to search across the encrypted message bodies.  To mitigate the aforementioned security risk with this approach, we encrypt the entire search index using the same private key used to decrypt one's E-mails.  Therefore, the only risk would be if an adversary got access to one's private key, but that of course would have even worse security implications since he or she could then read all of the original E-mails anyway.

Our proof-of-concept solution is a tool called Magiic.  Magiic Allows for GPG Indexing of IMAP on the Command-line.  It is a Python script that uses GnuPG for encryption/decryption and Whoosh for full-text indexing.  It acts as a standalone mail application, connecting directly to an IMAP server and creating a local index off of the contents.  It has a simple ncurses interface so all interaction can take place on the command line.  We are releasing the code using a version of the Creative Commons BY-NC-SA 3.0 license that has been modified slightly to be more applicable for software licensing.  It is free for non-commercial use.  The code is available here.

Read More

How to debug Android Native Code with Eclipse

This blog summarizes the steps needed to set-up your Eclipse environment to support the debugging of an Android native application written in C/C++. It's taken from Carlos Suoto's web page at http://www.eclipse.org/sequoyah/documentation/native_debug.php.

1. Pre-Requisites

• Make sure you compile your C/C++ with the "-g" option (or use -DCMAKE_BUILD_TYPE:STRING="Debug" if you use cmake).
• Make sure APP_OPTIM is set to "APP_OPTIM:=debug" in Android.mk and Application.mk.
• Make sure build/core/build-binary.mk in Android NDK doesn't strip executables. For example patch android-ndk-r8e/build/core/build-binary.mk to the following:
  
  --- build/core/build-binary.mk.orig     2013-08-21 11:06:39.818329442 -0400
  +++ build/core/build-binary.mk  2013-08-21 11:13:11.877214361 -0400
  @@ -485,10 +485,16 @@ $(LOCAL_INSTALLED): PRIVATE_DST       :=
   $(LOCAL_INSTALLED): PRIVATE_STRIP     := $(TARGET_STRIP)
   $(LOCAL_INSTALLED): PRIVATE_STRIP_CMD := $(call cmd-strip, $(PRIVATE_DST))
   
  +ifeq ($(APP_OPTIM),debug)
  +$(LOCAL_INSTALLED): $(LOCAL_BUILT_MODULE) clean-installed-binaries
  +       @$(HOST_ECHO) "Install        : $(PRIVATE_NAME) => $(call pretty-dir,$(PRIVATE_DST))"
  +       $(hide) $(call host-install,$(PRIVATE_SRC),$(PRIVATE_DST))
  +else
   $(LOCAL_INSTALLED): $(LOCAL_BUILT_MODULE) clean-installed-binaries
          @$(HOST_ECHO) "Install        : $(PRIVATE_NAME) => $(call pretty-dir,$(PRIVATE_DST))"
          $(hide) $(call host-install,$(PRIVATE_SRC),$(PRIVATE_DST))
          $(hide) $(PRIVATE_STRIP_CMD)
  +endif

1.1. Install the Eclipse Sequoyah plugin

1. In Eclipse go to Help -> Install New Software
2. Click on the Add button
3. Enter 'Sequoyah Metadata Repository' in the Name field
4. Enter 'http://download.eclipse.org/sequoyah/updates/2.0/' in the Location field
5. If you still see the "There are no categorized items" message, uncheck the "Group items by category" radio button
6. Select "Sequoyah Android Native Code Support" and install the plugin

1.2. Convert The Android Java Application into C/C++ Project

You must convert your Java project to C/C++ using the Sequoyah plugin or else you won't be able to see the configuration options to set the proper debugger settings.

1. In Eclipse select the Android Java project you need to convert
2. Right click with the mouse and select Android Tools -> Add Native Support

1.3. Other Pre-Requisites

1. The platform must be Android 2.2 (android-8) or later
2. The ndk version must be r4b (it contains bugfixes to ndk-gdb that are necessary) or later
3. Eclipse CDT 7.0 or newer must be installed
4. The AndroidManifest.xml must have the property of the application node android:debuggable="true"
5. The build must have been done with the ndk-build (if using the Sequoyah Android components, it will be automatic)

2. Configurations

• 01) Create a debug configuration for an Android application (can be done with Eclipse or MOTODEV Studio)
• 02) Create a debug configuration for a C/C++ application
• 03) Set the following properties:
  
  
• 04) The process launcher must be the Standard Process Launcher. This is selected at the bottom of the Main tab:
  
  
• 05) On the "Main" tab:
  the Field C/C++ Application: $PROJECT_PATH/obj/local/armeabi/app_process
• 06) On the "Debugger" tab:
  
  • field Debugger: gdbserver
  • On the "Main" subtab:
    
    
  • 07) GDB debugger: $NDK_PATH/build/prebuilt/$ARCH/arm-eabi-$GCC_VERSION/bin/arm-eabi-gdb
  • 08) GDB command file: $PROJECT_PATH/obj/local/armeabi/gdb2.setup
    [Windows users] Uncheck the "Use full file path to set breakpoints" option
  • On the "Connection" subtab:
    
    
  • 09) Type: TCP
  • 10) Hostname or IP address: localhost
  • 11) Port number: 5039 
  
  

  3. Instructions

• Open the ndk-gdb script that came with the android NDK and comment the last line (we are not calling the usual gdb client, but we will attach an Eclipse gdb session instead):
  
  

  •     # $GDBCLIENT -x $GDBSETUP -e $APP_PROCESS
    

• Insert a breakpoint in your Java code, preferably after all System.loadLibrary() calls. (To make sure that the debugger is correctly attached to the Java process)
• Launch the android debug and wait for it to reach the breakpoint
• From a Terminal session, in the project folder, run the modified ndk-gdb command. It should not attach to an gdb client, but call the gdbserver on the emulator and open a TCP port for connection (or in alternative if you have an Android device connected to your USB port, the ndk-gdb script will run gdbserver on the device itself).
• In the $PROJECT_PATH/obj/local/armeabi/, modify the gdb.setup file, removing the target remote:5039 statement. (For some reason, the Eclipse GDB session does not like this statement being done in the commands file). Rename this new file to gdb2.setup. This step need to be run just once, on the first debug session.
• Launch the C/C++ Application debug and wait for the Eclipse GDB session to fully connect to the emulator's gdbserver instance.

After following these steps, one can continue to debug the application as usual, using the "continue" option to let the execution flow until the next breakpoint is hit or by using the usual "step-in" to execute each statement individually. Setting a breakpoint on a Java statement that calls a native function through JNI and stepping into will place the user at the beginning of the native code.
Another way to set breakpoints in the C/C++ code is from Eclipse to click on File -> Open File and browse to the location of your source code. Then double-click on the line where you want to set the breakpoint.

Read More