Reverse engineering with GDB? Maybe

I’m learning a bit about reverse engineering, and I have to say: using GDB is a real pain. Gee, I wish I had IDA Pro right now! Anyway, GDB is a pain to use because I can’t view all the registers and flags at once. Allegedly, I should be able to also reverse-step in gdb 7 but I am not seeing the option to. I might need to custom compile my own. I’ll need to get a lot more comfortable with gdb so I can expand some tools for my own dev work. They should become quite valuable since gdb isn’t going anywhere soon.

Also, ‘gdb -tui’ and thank me later.

‘Ctrl-x 2’ will split the screen for source and assembly code. Then, ‘layout asm’, ‘break *start’, ‘run’, ‘step’ and ‘next.’ That’s the quick and dirty primer for you. Expect to see me talk more about this later.

Another security system update

I’m running into issues loading the GPG encrypted data into a Uint8Array which should then be read by OpenPGP.js. I am seeing a discrepancy between the values of what is going in the Uint8Array and what I am seeing in a hex editor. xxd hex editor shows a leading value of 133. The Uint8Array is showing a value of 125. I downloaded the gpg encrypted file and decrypted it with gpg2, so the file is actually valid. It must be how I’m transporting it. I’m loading over AJAX right now.

Here’s my first pass: OpenPGP.js Nightmare

I am getting an error on line 19 of the gist.

I’ll keep at it and see what I can uncover. I knew I was going to run into issues with encoding, especially with a language as hectic as JavaScript. Sometimes web developers forget that there’s anything but strings and numbers out there!

Security system update

I made a little bit of progress. I’ve added a textarea for the GPG private key. Basically, you just paste the ASCII private key into the textarea, we load it into openpgp, prompt for a password, then we begin decrypting all of the incident data. There’s a lot more work to be done here.

Redmine, AWS Backup, and more

So, I was looking for a private issue tracker for my personal use. I discovered Redmine and installed it on cloud AWS. I assigned it a domain name and now I can connect and check on my issues, estimating time etc.. It’s so extremely convenient. I hope to expand its utility into planning etc.. I’m already reaping the benefits of having priority management built in an accessible manner.

I’m toying with the idea of backing up my data to AWS. I can import a keypair, so the data should remain secure. Right now, I have a 512 GB Magnetic EBS volume attached to one of my micro instances. It should be interesting to try to upload the data to it and see what happens.

Redmine, codility, khanacademy, nasm, asm.js and some maintenance

I didn’t make any progress on the security system today. Instead, I worked on some other things. I did a little bit more configuration on Redmine. Now, I can track and queue things that I want to get done, and if done correctly, I should be able to track my own time.

I did the first part of the training from Codility. This was an interesting problem. I had to find the largest number of consecutive zeroes in a binary representation of an entire unsigned int. I accomplished this by while looping and shifting the number to the right and checking the value with & or %…I forget. Next time, I’ll copy my code. Anyway, I only got an 80%. So, I’ll need to do some more work there.

On KhanAcademy, I did some z-scores work. This is pretty simple work. It’s simple subtraction and division, table lookups, etc..

I also did a little bit more tutorial programming through nasm. I wanted to implement Fizzbuzz in ASM but didn’t quite get there. Instead, I am starting with a fibonacci sample from http://cs.lmu.edu/~ray/notes/nasmtutorial/ and adapting it to the Fizzbuzz problem. Writing it in assembly is a refreshingly low level challenge. There’s something therapeutic about the low level operations.

I’ve done a little investigation into asm.js and WebAssembly since the WebAsm announcement earlier this week. Basically, WebAsm and asm.js are compilation targets via emscripten. A project called binaryen, I believe, can convert asm.js to WebAsm. https://github.com/kripken/emscripten/wiki/WebAssembly

I hooked up my other TB drives, encrypted a partition on one of them and started copying things over. I detected a potential issue through SMART unfortunately. I need to watch that drive to see if it’s a real failure or just a false positive.

Security system update

Of course I couldn’t leave Rootcrit in the state it is right now. I have openpgp.js loaded finally. I may make a requirejs Mojolicious skeleton available, to make everyone’s life easier in the future.

Anyway, I’m generating a keypair in the browser. Very nifty. This could be a service all on its own, actually. It can be integrated into a public keyserver.

Next up, I’ll see about ‘uploading’ a private key to the javascript itself and then trying to decrypt the incident image data and display it to the user in place.

Security system update

I just couldn’t let the issue with Rootcrit go, so I did some debugging via carton on Mojolicious::Static. I discovered that it was a misunderstanding on my part. The documentation could be a little clearer on this one. When I access “localhost/public/x” it then tries to look in “/home/user/whatever/public/public/x” or in other words, I needed to omit “/public” from my script link. So, I can now move ahead with openpgp.js.

Progress on the security system

My plan was to add OpenPGP.js to the Rootcrit system, but unfortunately, I can’t seem to get Mojolicious to serve static files no matter what I do. I’m not sure if it’s a chmod issue or what. I can clearly see that it’s listed in the static files. I may seek help on StackOverflow for the mojolicious issue.

Instead of implementing the solution for Rootcrit, I’m moving ahead with working in Ruby on Rails. This means creating a few different small test case applications, working through railstutorial etc. before tackling the main event.

2015-11-14 Changes to WESS

Instead of continuing work on my class diagram, I started to look into the more typical work of setting up the infrastructure that the web app portion of WESS demands: users, roles, configs, ORMs, etc..

I should definitely revisit my drafting board. I thought of setting up some sequence diagrams, maybe use case diagrams for the install/login/administration aspect of it. Even these parts need to have a plan reflected before work can really begin. There’s a lot here to chew on, and a good balance of actual software construction, user interface design and UML planning needs to be found.

It may be beneficial to write many plugins for different parts of my application, to keep things organized via the plugin manager for mojolicious. I should keep this in mind when writing the class diagrams.

I also looked into how the routing and rendering systems works in mojolicious. I’ll continue to use the embedded perl. I’ll also definitely be taking serious advantage of CSS and JS, which will force the use of more modern browsers, but is worth the trade-off.