Security Ripcord

I’m not a funny guy and I am definitely not an artist.  But, in the spirit of Stick Kung Fu, XKCD, and Deep Inspection, I couldn’t help myself.  Everytime I miss the waste basket I am reminded of why I work in this field.

Jeremiah Grossman has a simple but sweet post about what to do on your first day of work when you come on board to a company that has no “no existing web/software security program.” He simply asked, “What is the very first thing do on day 1? [sic]”

The meat of the post is in the comments. Although it started out with some typical guidance on how to technically identify server, applications, vulnerabilities, and the like, the comments quickly transition into focus on the people of the organization. Getting to know the executives, management peers, security and technical administrators, and even support personnel before diving in and trying to find problems and giving orders about how to fix them.

Security Professionals need to remember that there are other people out there. It has often been said that we need to refrain from saying “No,” “Don’t,” “Can’t,” and other negatively connotative words unless absolutely necessary. We often remind ourselves that we are a part of the business unit and that we are, typically, support personnel rather than the front line administrators (and if you are both then your security tasks should take the support model into consideration). So when it all boils down, we are saying that we have to be a helpful and viable part of the business by working with the other employees, no matter the level, rather than being the lonesome cowboy with six-guns drawn. Once we have accomplished this then we can start delving into identify critical physical assets, location of data, mission critical application, and other important technically-related security information. Hopefully, your initial dealings with fellow employees and managers will have already greased the skids to start working with this information, but it will have also provided you with a better understanding of the politics and business necessities surrounding the current state of technical deployment.

I’m not going to repeat my or anybody else’s comments here. Go check out Jeremiah’s post and then put in your two cents. But while you are there, notice some of the names of people who are commenting on getting to know the people and organization first before diving into the technical aspect of the position. You will probably notice many people that you know and respect.

Go forth and do good things,

Don C. Weber

I’m willing to bet a few people I know are going to have opinions about this.

I was Googling something today when I was directed to Wikipedia. As I was reading I noticed the following link for “Portal: Computer Security”.

When I clicked on it I was redirected to a very interesting page full of security links and information. So, I started reviewing what they have included when I got to the “Selected biography” section. Well, the title of the post speaks for itself. Now, the image is a bit large and part of it is hidden. Just click on it and you’ll see the whole thing. Oh, and please feel free to comment

Go forth and do good things,

Don C. Weber

I would like to start off by saying, “You can’t!!” The quicker you come to grips with that the better off you will be in the long run. Politics, or perhaps Micro-Politics since I am talking about intra/inter-office politics, is just a fact of life. Everybody has an agenda whether it is to further themselves, further their family, further the company, or any number of other things. So, get over it because it is just going to happen.

Now, let me tell you how you can control politics. I’m not talking “hand of God” control. I’m talking about making it difficult for politics to adversely (because some politics are good) influence the security of your organization. The answer can be found in my previous post on Organized Security. The answer is “Document Your Processes!” Okay, that is not the full answer, but it is the start. Getting your processes written down and accepted is the first step. The thing that seems to be working the best for my team is to document a process’ flow before writing down the procedure. Understanding the actions, decisions, and touch points of a process before writing the document that details each action and decision point. Here is a simple example pertaining to a user account request. This process flow utilizes “swim lanes” to show different teams or departments.

Once you have created this flowchart it is very hard to justify a deviation from this process. It becomes even more difficult once you detail each box in your procedural documentation. Getting your management and each team or department listed in the “swim lanes” to sign off on their involvement with the process will decrease the deviation possibilities even more. And if all else fails, it will make deviations readily apparent to management and all of the teams or departments involved.

Now, this does not mean that deviations will not happen. It is a fact of life that a situation or event was not taken into consideration during the development of the process. These instances shouldn’t matter in the grand scheme. Once the event has happened and been addressed, the individuals responsible for the process should quickly run through the process to see if any documentation needs to be generated or additional actions taken. After everything has been addressed the team can conduct a lessons learn to determine if the process needs to be updated or if the deviation was just an anomaly that will rarely occur and can be addressed on a case by case basis. Of course, politics can fall into this category. But all of this, as I mentioned, makes the deviation very apparent and the extra work associated with running back through the process and evaluating the overall process should raise questions about the validity of the action.

Once everything is documented and approved there is another very important step. That step is to consistently apply the process. Lack of consistency will leave gaps in all of your processes. Lack of consistency will breed contempt for your system and provide individuals and groups the leverage they need to circumvent the process in question and possibility the other processes developed by your team.

In the end you are not going to solve politics in your organization. You and your team need to learn how to accept it as a part of doing business. Just remember, diligent documentation, repeatable processes, and consistent application will protect you as much as they can.

Go forth and do good things,

Don C. Weber

Well, this week at work was very interesting. Actually, the last two weeks have been extremely busy. As Friday rolled in I looked into the eyes of my team members and I could see the tired, slightly overwhelmed, and, for some, haggled look in their eyes. They had shouldered what our organization decided to throw at them and they pulled through with their heads held high. No small feat when you are talking about a crew with that was built from individuals with very little security background and a manager (me) who is hell-bent on documenting and improving each procedure as they are going through it. I do this not only to help them build a program that is repeatable and lends itself to self-improvement, but so that our customer can “feel-the-pain” when their goals are not being accomplished due to the never ending “high priority” additional tasks (something I, and others, refer to as “firefighting”).

I usually make it a point to congratulate my team members for a job well done. It builds confidence, denotes achievement, and helps give a sense of closure to on-going tasks and issues that never seem to have an “end.” But this week I went a step further. I let them know that when they are working on the “high priority” issues, when the “firefighting” is taking all of their time and effort, that the things they are doing are enough. Just working the task is enough to help secure our environment. Even if they haven’t completed the task or specific issues mean they were not able to address regular duties and other tasks, as long as they worked hard and smart, it is enough.

It has to be enough. No environment is ever going to be 100 percent secure. Security professionals and security cynics can all agree to that statement. But, when you look at it from the other end, no environment is zero percent secure either. Each operating system comes with some controls. So every environment starts a little bit “in the black.” As an organization starts adding personnel and controls they increase their security percentage. Finally, with the addition of security professionals and a well-rounded security approach, an organization sees its greatest jump towards the unobtainable 100 percent secure goal. Just dong things to move towards that endpoint is enough. And I think that sometimes organizations and managers forget that aspect of the big picture.

So, when you get back in the office next week, take a look around. Look at the accomplishments of your team members. Take note of these accomplishments and provide the appropriate praise to the situation. Let them know that their efforts are enough and that because of their actions the overall environment is more secure. Then look at the other individuals in your organization. Look at the system administrators, the desktop support personnel, the help desk operators, and everybody else. Look at their actions and point out their accomplishments as well. Let them know that they are helping secure the environment and that their actions are enough.

If you do this, you are doing enough and you are speeding up your progress towards that unobtainable goal.

Go forth and do good things,

Don C. Weber

I just noticed that my feeds were broken and I apologize to anybody who has missed my valuable contibutions to the security industry . I’m not sure how long this has been going on. I assume since I upgraded to WP 2.5.1. I turns out that either podPress or the Creative Commons plugins is not playing nice. I was getting the following lines concatenated in the feed:

• xmlns:creativeCommons=”http://backend.userland.com/creativeCommonsRssModule”
• xmlns:itunes=”http://www.itunes.com/dtds/podcast-1.0.dtd”

To fix it I added a leading “\n” to the “xmlns:itunes” line in podPress’s podpress_feed_functions.php. This fixed the problem although I do not know if is a podPress bug or a Creative Commons bug. I have jumped on a similar issue at the podPress forums. They are usually very helpful and I should get a response and know more soon.

Welcome back to all.  Please check and make sure you haven’t missed anything.  I have also published a few new pages you should check out.  And don’t forget to respond to the latest Security Ripcord Poll in the left sidebar.

Go forth and do good things,

Don C. Weber

This will show the capture of ping requests to a specific host. This information will be captured using tshark to a pcap file. This pcap file will be edited to cut out the ping reply packets. This file will then be used to replay the ping requests and receive responses.

This should be the first step to many similar replays.

Run tshark to capture

[user@localhost tshark]$ sudo /usr/sbin/tshark -i eth0 -w ping_default.pcap
Password:
Running as user “root” and group “root”. This could be dangerous.
Capturing on eth0
8
[user@localhost tshark]$

Ping remote host

[user@localhost tshark]$ ping -c 4 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=0.422 ms
64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=0.339 ms
64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=0.243 ms
64 bytes from 192.168.2.1: icmp_seq=4 ttl=64 time=0.334 ms

— 192.168.2.1 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3001ms
rtt min/avg/max/mdev = 0.243/0.334/0.422/0.065 ms
[user@localhost tshark]$

Read pcap file with tshark

[user@localhost tshark]$ sudo /usr/sbin/tshark -r ping_default.pcap
Running as user “root” and group “root”. This could be dangerous.
1 0.000000 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
2 0.000370 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
3 1.000509 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
4 1.000783 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
5 2.001345 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
6 2.001524 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
7 3.001984 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
8 3.002263 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
[user@localhost tshark]$

Rip out only the wanted packets

[user@localhost tshark]$ ls
ping_default.pcap
[user@localhost tshark]$ sudo /usr/sbin/editcap ping_default.pcap ping_requests.pcap 1 3 5 7
Password:
Add_Selected: 1
Not inclusive … 1
Add_Selected: 3
Not inclusive … 3
Add_Selected: 5
Not inclusive … 5
Add_Selected: 7
Not inclusive … 7
[user@localhost tshark]$ ll
total 16
-rw——- 1 root root 936 2008-05-17 23:33 ping_default.pcap
-rw-r–r– 1 root root 480 2008-05-17 23:35 ping_requests.pcap
[user@localhost tshark]$

Read pcap file with tshark

[user@localhost tshark]$ sudo /usr/sbin/tshark -r ping_requests.pcap
Running as user “root” and group “root”. This could be dangerous.
1 0.000000 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
2 1.000413 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
3 2.001154 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
4 3.001893 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
[user@localhost tshark]$

I am not sure why that happened. Grap the right packets with editcap.

[user@localhost tshark]$ sudo /usr/sbin/editcap ping_default.pcap ping_requests.pcap 2 4 6 8
Add_Selected: 2
Not inclusive … 2
Add_Selected: 4
Not inclusive … 4
Add_Selected: 6
Not inclusive … 6
Add_Selected: 8
Not inclusive … 8
[user@localhost tshark]$

Read pcap file with tshark

[user@localhost tshark]$ sudo /usr/sbin/tshark -r ping_requests.pcap
Running as user “root” and group “root”. This could be dangerous.
1 0.000000 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
2 1.000509 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
3 2.001345 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
4 3.001984 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
[user@localhost tshark]$

Replay with TcpReplay

[user@localhost tshark]$ sudo tcpreplay –intf1=eth0 ping_requests.pcap
sending out eth0
processing file: ping_requests.pcap
Actual: 4 packets (392 bytes) sent in 3.10 seconds
Rated: 130.2 bps, 0.00 Mbps/sec, 1.33 pps

Statistics for network device: eth0
Attempted packets: 4
Successful packets: 4
Failed packets: 0
Retried packets: 0
[user@localhost tshark]$

Capture replay with tshark

[userr@localhost tshark]$ sudo /usr/sbin/tshark -i eth0 -w ping_replay.pcap
Running as user “root” and group “root”. This could be dangerous.
Capturing on eth0
8
(process:8719): CaptureChild-INFO (recursed): Signal: Stop capture
aborting…
tshark: Child capture process died: Abort
[user@localhost tshark]$

Review what happened with tshark

[user@localhost tshark]$ sudo /usr/sbin/tshark -r ping_replay.pcap
Running as user “root” and group “root”. This could be dangerous.
1 0.000000 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
2 0.000332 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
3 1.001619 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
4 1.001905 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
5 2.002310 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
6 2.002494 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
7 3.003997 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
8 3.004201 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
[user@localhost tshark]$

Go forth and do good things,

Don C. Weber

I was checking prices for a few books that atlas mentioned in his interview on Learn Security Online. I was not expecting to pay this much for any of the books. I think I’ll wait. Those of you who are done with your versions might think about becoming a reseller. Or, you can contact me if you are willing to make a donation.

Go forth and do good things,

Don C. Weber

I’ve been doing a little running lately getting ready for the Corpus Christi Beach to Bay Relay. Today, instead of our usual four mile run, we decided to work on some sprints. We ran a mile and then started a series of 100 yard sprints with a 100 yard walk in between. Needless to say that the walking reset was filled full of huffing and puffing. At one point I noticed that I was hanging my head like most people do when they are tired. When I realized this I did what I always do, what I taught myself in the Marines after long runs and forced marches, I raised my head and started looking around. I use to do this because whenever you are the most tired is when you are the most vulnerable. You are not paying attention, you are breathing heavy, and you are doing everything you can just to take a break for a minute or two. Fortunately, the repercussions of me doing this now are not the same as they were back then.

All of this got me thinking about how we react to situations as a whole. I started thinking about how through training and effort we can begin to overcome hardships. I started thinking about how diligent practice can instill good habits and create muscle memory in any individual. Muscle memory is a condition where a body reacts without, or more precisely with only a little, thinking. You can see this by reviewing Rich Mogull’s posts on how he handled several car accidents after being out of the paramedics for a while. Rich did what came natural to him. He just reacted and, I’m sure, did a great job and a service.

“Yes, yes,” you are thinking to yourself right now. We have heard this all before. Practice makes perfect. Practice your incident response. Practice your backup procedures. Practice your disaster recovery. Practice makes perfect. Practice, Practice, Practice. Blah, blah, blah. Yes, I am tell you that. But what I want to emphasize is that you can train yourselves all day long and still make mistakes.

Running with my head down took me back to the days of running through the hills of Camp Pendleton and training myself to keep my head up and aware of my surroundings no matter how tired I was at the time. But what it really got me thinking about was being in the stack. Not the stack you are use to hearing about, the stack of Marines that are just about to enter a building or room that may contain hostiles. It didn’t matter where we were, once people started lining up and getting ready to move to action, their heads dropped. Not because they were tired or lazy, but because they were focused and waiting. Like a spring ready to uncoil all of its power. This occurred so often that it was not surprising to hear, “Keep your heads up in the stack!” whispered over the radio. Or have someone give you a quick rap on the helmet as a reminder. Everybody did it, everybody got sucked into it, and everybody was aware of it and watched out for their buddy, because that person was watching out for them.

So, how does this apply to us? Well, security professionals have a lot to accomplish on any given day. Logs to review, servers to patch, incidents to respond to, training to develop and give (and that is just the short list). Let’s face it. We are swamped with responsibility and duties. Everybody groans when we walk into a room but everybody notices when our duties start falling behind because it directly affects their business. With all of this activity, with all of this responsibility, it is very easy to get set into a common routine or mode. It is very easy for our heads to drop into our computers, logs, management consoles, spreadsheets, etc. We are doing our jobs and we are getting it done, but are we aware of our surroundings. Are we aware of the common sights and sounds of the office environment and server room. Are we listening to people talk when they need our guidance, input, or for us to listen for listening’s sake?

If you are, then good on you. Now look around and see who is not. Please, tap them on the head and tell them, “Keep your head up in the stack!”

Go forth and do good things,

Don C. Weber

Although my last foray into assembly via a Hello World program was helpful, it only scratched the surface. I was thinking about moving onto some user input programs next when I realized that it might be more helpful if I learned how to do some quick arithmetic using assembly. To do this I located some additional resources to help my understanding of assembly.

• Using Assembly Language in Linux
• Linux System Call Table
• x86 Assembly Programming

Together with my old version of Hello World I created an assembly program that would print out a “Number is 0″ and then “Number is 1″. My intention was to set a register to 0 and then to increment the register so that it equaled 1. The following is the program.

DISCLAIMER UPDATE:  The following assembly code does not work.  That is the point.  The walk through after the code, however, does help.

// Assembly Arithmetics

.data
NUMS:
.string “Number is ”
NUMSLEN:
.short $-NUMS
EOL:
.string “\n”
EOLLEN:
.short $-EOL

.text
.globl _start

_start:
//Print NUMSTRING
movl $4,%eax
movl $1,%ebx
movl $NUMS,%ecx
movl $NUMSLEN,%edx
int $0×80

//Make a register equal to zero and print
xor %ecx,%ecx
xor %edx,%edx
inc %edx
int $0×80

//Print EOL
movl $EOL,%ecx
movl $EOLLEN,%edx
int $0×80

//Print NUMSTRING
movl $NUMS,%ecx
movl $NUMSLEN,%edx
int $0×80

//Increment register from zero to one
xor %ecx,%ecx
xor %edx,%edx
inc %ecx
inc %edx
int $0×80

//Print EOL
movl $EOL,%ecx
movl $EOLLEN,%edx
int $0×80

//Exit
ret

To help me compile this I also created a quick Makefile.

arth.as: arth.as.o
ld arth.as.o -o arth.as.exe
arth.as.o: arth.as.s
as arth.as.s -o arth.as.o

This Makefile allowed me to just type “make” every time that I needed to make a change to the assembly program. This happened several times before I came to the assembly program above. Once I had the executable, I thought I was good to go. Unfortunately.

bt as # ls
Makefile arth.as.s
bt as # make
as arth.as.s -o arth.as.o
ld arth.as.o -o arth.as.exe
bt as # ls
Makefile arth.as.exe* arth.as.o arth.as.s
bt as # ./arth.as.exe
Number is

Segmentation fault
bt as #

Dang ol’ Seg fault. What do I do now? Well, I was going to start moving things around and checking against other simple programs available via Google when I remembered that I could step through the executable using VTrace. After a little trial and error I taught myself to attach to the executable, step through each instruction, pull all of the registry values, pull selected registry values, and run the program all of the way through. The following output shows each of these steps. You will notice that I decided to start using several arrays to help me consistently output the values of the registers.

IDLE 1.1.3
>>> import vtrace
>>> tr = vtrace.getTrace()
>>> tr.execute(’/root/Development/test_programs/c/misc/as/c_stuff.as.exe’)
>>> tr.getPid()
11683
>>> arrRegs = ['eax','ebx','ecx','edx']
>>> for i in arrRegs:
print “%s : %s” % (i,tr.getRegisterByName(i))

eax : 0
ebx : 0
ecx : 0
edx : 0
>>> arrAllRegs = tr.getRegisters()
>>> for key in arrAllRegs:
print “%s : %s” % (key,arrAllRegs[key])

debug1 : 0
debug0 : 0
debug3 : 0
debug2 : 0
debug5 : 0
debug4 : 0
debug7 : 0
debug6 : 0
edi : 0
eax : 0
cs : 115
fs : 0
ebp : 0
__fs : 0
__cs : 0
gs : 0
edx : 0
ebx : 0
ds : 123
__es : 0
ecx : 0
eip : 134512756
esp : 3213311088
ss : 123
__ds : 0
__ss : 0
__gs : 0
eflags : 2097798
es : 123
orig_eax : 11
esi : 0
>>> tr.run()
>>> arrAllRegs = tr.getRegisters()
>>> for key in arrAllRegs:
print “%s : %s” % (key,arrAllRegs[key])

debug1 : 0
debug0 : 0
debug3 : 0
debug2 : 0
debug5 : 0
debug4 : 0
debug7 : 0
debug6 : 0
edi : 0
eax : 4294967258
cs : 115
fs : 0
ebp : 0
__fs : 0
__cs : 0
gs : 0
edx : 134516943
ebx : 1
ds : 123
__es : 0
ecx : 134516941
eip : 1
esp : 3213311092
ss : 123
__ds : 0
__ss : 0
__gs : 0
eflags : 2163202
es : 123
orig_eax : 4294967295
esi : 0
>>> for i in arrRegs:
print “%s : %s” % (i,tr.getRegisterByName(i))

eax : 4294967258 <- NOTE: Remember these values for later
ebx : 1
ecx : 134516941
edx : 134516943
>>> tr.detach()
>>> tr.getPid()
0
>>>

Okay, that didn’t help. I guess I need to step through using “tr.stepi()” and output the registry value after each step. Let’s see if it helps. I have inserted the assembly code as NOTE: throughout the output.

IDLE 1.1.3
>>> import vtrace
>>> tr=vtrace.getTrace()
>>> tr.getPid()
0
>>> tr.execute(’/root/Development/test_programs/c/misc/as/arth.as.exe’)
>>> tr.getPid()
14727
>>> arrAllRegs = tr.getRegisters()
>>> for key in arrAllRegs:
print “%s : %s” % (key,arrAllRegs[key])

debug1 : 0
debug0 : 0
debug3 : 0
debug2 : 0
debug5 : 0
debug4 : 0
debug7 : 0
debug6 : 0
edi : 0
eax : 0
cs : 115
fs : 0
ebp : 0
__fs : 0
__cs : 0
gs : 0
edx : 0
ebx : 0
ds : 123
__es : 0
ecx : 0
eip : 134512756
esp : 3220532048
ss : 123
__ds : 0
__ss : 0
__gs : 0
eflags : 2097798
es : 123
orig_eax : 11
esi : 0
>>> arrRegs = ['eax','ebx','ecx','edx']
>>> for i in arrRegs:
print “%s : %s” % (i,tr.getRegisterByName(i))

eax : 0 <- NOTE: All registers appear to start clean
ebx : 0
ecx : 0
edx : 0
>>> tr.stepi()
>>> for i in arrRegs:
print “%s : %s” % (i,tr.getRegisterByName(i))

eax : 4 <- NOTE: movl $4,%eax
ebx : 0
ecx : 0
edx : 0
>>> tr.stepi()
>>> for i in arrRegs:
print “%s : %s” % (i,tr.getRegisterByName(i))

eax : 4
ebx : 1 <- NOTE: movl $1,%ebx
ecx : 0
edx : 0
>>> tr.stepi()
>>>
>>> for i in arrRegs:
print “%s : %s” % (i,tr.getRegisterByName(i))

eax : 4
ebx : 1
ecx : 134516928 <- NOTE: movl $NUMS,%ecx
edx : 0
>>> tr.stepi()
>>> for i in arrRegs:
print “%s : %s” % (i,tr.getRegisterByName(i))

eax : 4
ebx : 1
ecx : 134516928
edx : 134516939 <- NOTE: movl $NUMSLEN,%edx
>>> tr.stepi()
>>> for i in arrRegs:
print “%s : %s” % (i,tr.getRegisterByName(i))

eax : 2048 <- NOTE: int $0×80 I’m not sure why this register changed UPDATE: Confirmed, this register is changed with the result of “int $0×80″, which means the next “int $0×80″ will do the system call assigned to 2048 or $0×800
ebx : 1
ecx : 134516928
edx : 134516939
>>> tr.stepi()
>>> for i in arrRegs:
print “%s : %s” % (i,tr.getRegisterByName(i))

eax : 2048
ebx : 1
ecx : 0 <- NOTE: xor %ecx,%ecx
edx : 134516939
>>> tr.stepi()
>>> for i in arrRegs:
print “%s : %s” % (i,tr.getRegisterByName(i))

eax : 2048
ebx : 1
ecx : 0
edx : 0 <- NOTE: xor %edx,%edx
>>> tr.stepi()
>>> for i in arrRegs:
print “%s : %s” % (i,tr.getRegisterByName(i))

eax : 2048
ebx : 1
ecx : 0
edx : 1 <- NOTE: inc %edx
>>> tr.stepi()
>>> for i in arrRegs:
print “%s : %s” % (i,tr.getRegisterByName(i))

eax : 4294967258 <- NOTE: int $0×80 Okay, this is probably the segfault, but VTrace doesn’t stop stepping here
ebx : 1
ecx : 134516941 <- NOTE: movl $EOL,%ecx I’m also not sure why it seems like it stepped twice and executed the next instruction
edx : 1
>>> tr.stepi()
>>> for i in arrRegs:
print “%s : %s” % (i,tr.getRegisterByName(i))

eax : 4294967258
ebx : 1
ecx : 134516941
edx : 134516943 <- NOTE: movl $EOLLEN,%edx
>>> tr.stepi()
>>> for i in arrRegs:
print “%s : %s” % (i,tr.getRegisterByName(i))

eax : 4294967258
ebx : 1
ecx : 134516928 <- NOTE: movl $NUMS,%ecx
edx : 134516943
>>> tr.stepi()
>>> for i in arrRegs:
print “%s : %s” % (i,tr.getRegisterByName(i))

eax : 4294967258
ebx : 1
ecx : 134516928
edx : 134516939 <- NOTE: movl $EOLLEN,%edx
>>> tr.stepi()
>>> for i in arrRegs:
print “%s : %s” % (i,tr.getRegisterByName(i))

eax : 4294967258
ebx : 1
ecx : 0 <- NOTE: xor %ecx,%ecx
edx : 134516939
>>> tr.stepi()
>>> for i in arrRegs:
print “%s : %s” % (i,tr.getRegisterByName(i))

eax : 4294967258
ebx : 1
ecx : 0
edx : 0 <- NOTE: xor %edx,%edx
>>> tr.stepi()
>>> for i in arrRegs:
print “%s : %s” % (i,tr.getRegisterByName(i))

eax : 4294967258
ebx : 1
ecx : 1 <- NOTE: inc %ecx
edx : 0
>>> tr.stepi()
>>> for i in arrRegs:
print “%s : %s” % (i,tr.getRegisterByName(i))

eax : 4294967258
ebx : 1
ecx : 1
edx : 1 <- NOTE: inc %edx
>>> tr.stepi()
>>> for i in arrRegs:
print “%s : %s” % (i,tr.getRegisterByName(i))

eax : 4294967258
ebx : 1
ecx : 134516941 <- NOTE: movl $EOL,%ecx
edx : 1
>>> tr.stepi()
>>> for i in arrRegs:
print “%s : %s” % (i,tr.getRegisterByName(i))

eax : 4294967258 <- NOTE: Complete run through stopped here
ebx : 1
ecx : 134516941
edx : 134516943 <- NOTE: movl $EOLLEN,%edx
>>> tr.stepi()
>>> for i in arrRegs:
print “%s : %s” % (i,tr.getRegisterByName(i))

eax : 4294967258
ebx : 1
ecx : 134516941
edx : 134516943
>>> tr.stepi()
>>> for i in arrRegs:
print “%s : %s” % (i,tr.getRegisterByName(i))

eax : 4294967258 <- NOTE: Step through stops here as well
ebx : 1
ecx : 134516941
edx : 134516943
>>> tr.detach()
>>> tr.getPid()
0
>>>

Not much help there. Basically, VTrace will step right through a segmentation fault. Although, now that I run through the program step by step I think I can see where the program failed. I guess the “int $0×80″ changes the register $eax. I believe this means that I have to reset this value before writing.

What still bothers me though is the fact that VTrace did not stop on the segmentation fault. I thought debuggers did this. That is when I realized that VTrace is not necessarily a debugger. Actually VDB is a debugger and I should have used that instead of troubleshooting with VTrace. I guess I could just reset the register before telling it to print, I think I’ll try VDB to see if it will help me identify the exact step where the executable stops.

More assembly soon!!

UPDATE: As I mentioned inline, the call “int $0×80″ writes it’s return value to %eax. This means that I will l have to update %eax with a decimal 4 every time I want to write out. Also, I have come to realize that whether I use VTrace, VDB, or GDB no debugger is going to help me overcome bad code. I guess I need a book because online resources don’t seem to be cutting it for me. I did find one resource that mentioned that the values in the registers are not necessarily ASCII and that they will need to be converted before being output. But then the same resource went straight into memory modification to write the number with the original string instead of outputting them one at a time like I have here. I’m going to try and get a grasp on this before I start delving into memory modification.

Go forth and do good things,

Don C. Weber