The page contains documentation about architectures, assembly, instruction set, ISA or whatever you name it:
x86 (both x86 and x64)
ARM
http://www.ch01a.net/static/armref/index.html
Power PC
http://web.archive.org/web/20071006155454/www.nersc.gov/vendor_docs/ibm/asm/alangref02.htm
SPARC
http://www.cs.unm.edu/~maccabe/classes/341/labman/labman.html
MDB (acronym for Modular Debugger) is a debugger by Oracle and it is mostly found on Solaris machines. If you need to debug a user application in Solaris, MDB might be the tool for you (along DBX and GDB). MDB support both Sparc and x86. MDB’s greatest advance among the other is that it comes with every Solaris machine. So if you find yourself on a Sparc machine running Solaris, surrounded with binary files and executables you are not familiar with, attack them with MDB!!
In this post I write commands I used. This is a personal post 🙂
ENTER LEAVE MDB
Launch mdb to debug [executable file]:
$ mdb [executable file]
Exit mdb:
> ::quit
BREAKPOINTS
Set breakpoint
> [address] ::bp
EXECUTION CONTOL
Run executable (Can be used multiple times, there is no need to relaunch MDB)
> ::run
> :r
Step into instrucion
> ::step
> :s
Step over instruction – Refer to a function called from instruction as a single instruction. Can also be used instead of ::run
> ::next
> :e
Display Information
Show register
> ::regs
Notes to myself:
When debugging sparc remember that due to delayed execution (pipelined architecture) registers gets updated only after 2 instruction executions.
For additional reading:
The Oracle Solaris Modular Debugger Guide
The Cheeta c50 is a GPS console that provides a great protection against static speed cameras and other static or foreknown hazards. It uses an update file (.hdr) with the coordinates and azimuth of the dangers ahead. Since the console should be updated on casual basis, an update pack should be purchased aside the console. to gain access to the actual speed traps and dangers. Without it the user will not be notified about new speed traps.
About a year ago I bought the c50 v7 and figured that there is a chance I could home-brew an update file without paying for a binary presentation of freely available widespread information.
To make a long story short,
Cheetah c50 with homebrew DB
Here are some funny things about the c50.
1. The c50 allows one to save Points of Interest (POI) and export those POI to csv. This is the format the c50 crew was using: The lat\longitudes are deserialized to int and gain a decimal point after the second digit.
example:
Serialize
34.71337 -> 3471337 -> 0x34f7e9 -> 0x0034f7e9 -> 0xE9 0xF7 0x34 0x00
The same serialization is used for the DB coordinates.
2. Most of the READ/WRITE functions send a hard coded command to device. However, the UpdateDB function was not implemented that way. It seems as if the command telling the device to update it’s DB is a part of the update file (and perhaps the .hdr extension of the update file stands for header).
My research and production scripts can be found here
I would like to thank
Ruby Feinstein
Zeev Greenberg
Tamir Mayer
Mark Bloch
aandy on freenode
For their kind help and support
CodeRetreat2012 was a blast! I really enjoyed it. This was my first CodeRetreat.
CodeRetreat is a hackathon made of sessions, in every session programmers are pairing and trying to solve Conway’s Game of Life. In every session there is a restriction about the development method.
In this note I’ll try to sum my thoughts about CodeRetreat2012 day that took part in Tel-Aviv-Jaffa in the office of EBay-Israel (Who host this event second year) and by the generous and wonderful hosting of Yonatan Bergman and Aviv Ben-Yosef.
There where six sessions in this day, I used python on most of them. Here are my notes:
Session – 0 – Warm up
Paired with: None
Restrictions: None
I woke up late 😛
Session – 1
Paired with: Uri Sivan
Restrictions: A function must not receive primitives.
This session result in a code larger then needed with 3 classes (Life, Grid, Coord). However, those extra classes caused every method to work exactly in its own domain. Coord had a method yielding neighbor coordinates. Grid wrapped the matrix and had a method that yields all coordinates. Life implemented only methods regarding the game of life. Our code distribution was very ‘sane’ and made a lot of sense, way more then expected.
A trick Uri came up with was to use a larger matrix then needed in order to handle offset overflows.
Session – 2
Paired with: Roy Rothenberg.
Restrictions: Ping-Pong Test-Driven-Development and no function larger then 4 lines of code.
This was my first time using TDD methodology so I can’t say I fully grasped the gist of it. For the most part we just focused on not exceeding the 4 lines limit, and boy did that escalated quickly… It turned into a 1-liner contest. every line of code was merged into a 1 liner, and when bugs occurred it was hell to find where exactly.
A trick Roy came up with was the Pythonic trinary operator(aka ?:) form: a = (4 == 5) and "yes" or "God damn!"
Session – 3 – The evil mute programmer.
Paired with: Elad Mallal.
Restrictions: TDD when one is the tester and the other is the developer. The developer should pass all tests without creating any real useful code (hence the Evil) and NO COMMUNICATION BETWEEN THEM IS ALLOWED.
Elad was the tester and I was the programmer. Even though it was fun it was not very productive. Seeing Elad’s tests I think I finally understood the idea behind TDD and it power. Elad’s simple tests forced me into a strict design he had planned.
Session – 4 – The best session!
Paired with: Igal Kreichman
Restrictions: No return statements allowed.
The no return statement restriction caused us to save the return values as class members – in fact it redefined the domain of every class. The final code was, by my opinion, the best code I worked on during the whole day and I bring it here after a minor bugfix 🙂
import random """ @date: December 8th 2012 """ class Cell(): def __init__(self, x, y, maxx, maxy): self.x = x self.y = y self.maxx = maxx self.maxy = maxy self.neighbours = 0 def calc_neighbours(self, old_state): self.neighbours = 0 for i in xrange(max(0, self.x -1), min (self.maxx, self.x+2)): for j in xrange(max(0, self.y -1), min(self.maxy, self.y+2)): if i == self.x and j == self.y: continue if isinstance(old_state[i][j], LiveCell): self.neighbours += 1 def calc_new_state(self): pass def next_gen(self, old_state, new_state): self.calc_neighbours(old_state) self.calc_new_state() new_state[self.x][self.y] = self.new_state class DeadCell(Cell): def __init__(self, x, y, maxx, maxy): Cell.__init__(self, x, y, maxx, maxy) def calc_new_state(self): self.new_state = (self.neighbours == 3) and LiveCell(self.x, self.y, self.maxx, self.maxy) or DeadCell(self.x, self.y, self.maxx, self.maxy) class LiveCell(Cell): def __init__(self, x, y, maxx, maxy): Cell.__init__(self, x, y, maxx, maxy) def calc_new_state(self): self.new_state = (self.neighbours in [2,3]) and LiveCell(self.x, self.y, self.maxx, self.maxy) or DeadCell(self.x, self.y, self.maxx, self.maxy) class Board(): def __init__(self, dim, lives = []): self.dim = dim self.grid = [[DeadCell(i, j, dim, dim) for j in xrange(dim)] for i in xrange(dim)] density = len(lives) for i in xrange(dim): for j in xrange(dim): if random.choice(xrange(density)) == 0: self.grid[i][j] = LiveCell(i,j,dim,dim) """ for l in lives: self.grid[l[0]][l[1]] = LiveCell(l[0],l[1],dim,dim) """ def print_it(self): printval = "" for i in xrange(self.dim): printval += "\n" for j in xrange(self.dim): printval += "." if isinstance(self.grid[i][j], DeadCell) else "X" print printval print "---" * 5 def step(self): new_grid = [[DeadCell(i, j, self.dim, self.dim) for i in xrange(self.dim)] for j in xrange(self.dim)] for i in xrange(self.dim): for j in xrange(self.dim): self.grid[i][j].next_gen(self.grid, new_grid) self.grid = new_grid def main(): b = Board(6, [(2,2),(2,3),(2,4),(2,5)]) b.print_it() b.step() b.print_it() main()
Session – 5 – Freestyle
Paired with: Anton Kucherov
Restriction: None
Extras: Matrices are not allowed and unlimited board.
Each of those extra’s we took upon ourselves may sounds hard but it’s quite the opposite. Unlimited boards does not need an overflow-safety code and without using matrices all one needs is to save a list (or a dictionary) of the ‘alive’ cells. It took us 17 minutes to finish this code and another 10 to improve it. It’s not very beautiful, but it was fun nonetheless. So here is our implementation for Conway’s Game of Life with no matrices:
def produce_deadlist(lives):
dead_dict = {}
for l in lives.keys():
count = 0
for xx in [-1,0,1]:
for yy in [-1,0,1]:
(x,y) = (l[0] + xx, l[1] + yy)
p = (x,y)
if xx == 0 and yy == 0:
continue
if p in lives.keys():
lives[p] += 1
else:
if not p in dead_dict.keys():
dead_dict[p] = 1
else:
dead_dict[p] += 1
return dead_dict
def main():
lives = [(-1,1),(-1,2),(-1,3)]
for i in range(10):
lives = step(lives)
print lives
def step(lives):
lives_dict = {}
for live in lives:
lives_dict[live] = 0
dead_dict = produce_deadlist(lives_dict)
new_lives = []
for l in lives:
if lives_dict[l] in [2,3]:
new_lives.append(l)
for d in dead_dict.keys():
if dead_dict[d] in [3]:
new_lives.append(d)
return new_lives
main()
Here are a couple of recommendations for people going to a CodeRetreat event:
* Leave the esoteric editor configurations at home or at least bring another ‘clean’ editor
* Don’t be shy – try to develop in a language you are not familiar with.
* Don’t use Visual Studio unless you have an i7 and SSD drive.
See ya next year!
! Photos are taken from Aviv Ben-Yosef and Yonatan Bergman‘s instagram accounts and I do not hold any rights of those photos.
I downloaded some color schemes for vim but couldn’t decide which one to use – so why not use them all?
Here is a small script I wrote for changing color scheme, works on vim and gvim.
The string in the ‘schemes’ variable are the file names (without the extension) of the *.vim files located at the scheme directory (‘colors’).
let schemes = 'stingray sean reloaded maroloccio3 dw_yellow dw_red dw_blue dw_cyan dw_green dw_orange darkzen'
let seconds = str2nr(strftime('%S'))
execute 'colorscheme '.split(schemes)[seconds%11]
redraw
Put this code in your .vimrc file on startup for happy coding 🙂
Look at the following opcode:
mov eax, ecx
There are two ways to assemble it to machine-code:
8b c1 and 89 c8.
First, look at the binary representation:
8b c1 = 1000 1011 1100 0001 = 100010 1 111 000 001
89 c8 = 1000 1001 1100 1000 = 100010 0 111 001 000
Let us analyze the differences within the binary representation. The prefix is the same (100010), and the source bits and the destination bits contain the same data. However, the one bit that changes is the direction bit (the “1” in the first and the “0” in the second). As one can ascertain, this is because this bit indicates the “direction”, either from first reg to second reg or from second reg to first reg.
Both machine-code bytes have the same meaning and they both disassemble back to the same assembly line “mov eax, ecx“. The same goes for every two-register input opcode such as add, sub, or, and, xor, etc. (but not for mul, div, in, out, etc.)
The fact that the x86 assembler is not injective is important to remember for the next time you are searching for a specific binary code in a binary file, writing an anti-virus program, or writing any other program that looks for specific binary bytes. Additionally, looking at the binary representation of an opcode helps you understand it better.
It is well known that one of the principles of “good programming” is the separation of code into functions, classes, namespaces, files, etc. There are many explanations for this separation. One reason is the idea that a bunch of codelines (or logic) should not appear more then once in the code so it will be possible to modify the code only once to affect all parts in the code that use the same logic. This principle is well described and known simply as DRY (Don’t Repeat Yourself) and DIE (Duplication Is Evil).
I worked on an IDAPython project where another colleague added GUI to the project’s interface. The person who wrote the GUI left the company without the time to finish the GUI feature, so we got left with a half-done GUI that could only run one time per IDA session. Runing the GUI script twice resulted in a crash for the script and for IDA.
At first, while debugging the script in order to find the cause for this devious bug, we had to reopen IDA every time. Later – we discovered that reopening the IDB without reopening IDA was enough. This was a good hint for us that perhaps the problem was not within IDA but somewhere else.
After a while we discovered that the cause for the crash was within our very own code. The GUI code relied on values from sys.argv to determine the relative path of the images for the GUI. The first time the script ran the value of sys.argv, it accurately contained the path of the script, but on second run it was a list containing an empty string ([”]).
Now we must ask, why was sys.argv modified and by whom? At the end of the first run its value was the same as in the beginning. Before jumping into IDAPython’s source code we ran a little test.
import sys print sys.argv
We saved this two-liner script twice under different names and ran them one after another and did not receive empty string in result. Running one of the scripts a second time using [Alt + 7] gave the familiar error of empy string in sys.argv.
Let us look at the source:
This is the code that runs by pressing [Alt + 9] (\python\init.py)
def runscript(script):
"""
Run the specified script after adding its directory path to
system path.
This function is used by the low-level plugin code.
"""
addscriptpath(script)
watchdog.reset()
argv = sys.argv
sys.argv = [ script ]
execfile(script, globals())
sys.argv = argv
* Notice the proper handling of sys.argv to emulate a real script running.
Now look at what happens at [Alt + 7] (somewhere at the source of IDAPython in a .cpp file):
/* History of previously executed scripts */
/* Default hotkey: Alt-7 */
void IDAPython_ScriptBox(void)
{
PyObject *module;
PyObject *dict;
PyObject *scriptbox;
PyObject *pystr;
/* Get globals() */
/* These two should never fail */
module = PyImport_AddModule("__main__");
dict = PyModule_GetDict(module);
scriptbox = PyDict_GetItemString(dict, "scriptbox");
if (!scriptbox)
{
warning("INTERNAL ERROR: ScriptBox_instance missing! Broken init.py?");
return;
}
pystr = PyObject_CallMethod(scriptbox, "run", "");
if (pystr)
{
/* If the return value is string use it as path */
if (PyObject_TypeCheck(pystr, &PyString_Type))
{
begin_execution();
ExecFile(PyString_AsString(pystr));
end_execution();
}
Py_DECREF(pystr);
}
Not only is the [alt+7] logic implemented in a different code file then the [alt-9] one (although the two have a strong connection), but also it is missing some of the logic of [alt+9], the logic that stores the values of argv for every script.
Therefore, this was not the right way to implement it.
*Sidenote, this bug was found on IDAPython 1.0 and 1.2.
A week ago Hexrays published IDA Pro 5.7’s new feature.
The main goal of the feature is both to simplify and to extend the ability of IDA Pro to run scripts (idc and IDAPython) from command line, and by doing so, to ease automation of script execution.
Some of you IDAPython users might ask, “What’s the big deal?! IDAPython already allows me to execute scripts from command line.” Well – Hexrays also added the crucial feature of passing arguments to the script.
Now, I don’t use IDA 5.7, but I do use both IDA Pro 5.2 and 5.5.
So – how can I pass arguments to IDAPython script through command line?
I figured out two ways to do so:
1. Build a procexp-like process tree to figure out which process is the parent process of the python engine process and then get its command line.
2. Abuse the ‘pass arguments to plugin‘ ability of IDA:
IDA allows plugins to receive arguments from command line:
idag.exe -O:ARG1:ARG2:ARG3: ... :ARGn
And plugins pull the arguments:
idaapi.get_plugin_options(plugin_name)
But plugins can also pull another plugin’s arguments 🙂
idaapi.get_plugin_options(another_plugin)
And they can also pull arguments that were sent to plugins that don’t exist:
idaapi.get_plugin_options(this_plugin_does_not_exist)
So basically if you want to pass arguments to your IDAPython script you can simply pass arguments to a plugin that doesn’t exist (I use Pype) and pull those arguments from your script 🙂
For example, from commandline:
cmd:
idaw.exe -A -OIDAPython:"c:\ida_scripts\script.py" -OPype:bla "c:\proj\interesting.idb"
and python:
if get_plugin_options("Pype") == "bla": idc.exit(5)
And this is how you pass arguments to scripts on IDA 5.1, 5.2, 5.3, 5.4, 5.5 and 5.6.
By the way- I only checked this on 5.2 and 5.5 but I am certain it will work – Good luck!
Accessomat's Blog 