Author Topic: O2 Source ?  (Read 32667 times)

0 Members and 2 Guests are viewing this topic.

Charles Pegge

  • Guest
Re: O2 Source ?
« Reply #30 on: July 28, 2011, 01:29:39 PM »
It will provide good exercise for your program  ;D

This stuff squashes down to a 4k EXE file. of which about 1.5k is padding.

Normally you never see it so it is quite a shock when all the opcodes and link information is made visible

Charles
« Last Edit: July 28, 2011, 01:38:34 PM by Charles Pegge »

efgee

  • Guest
Re: O2 Source ?
« Reply #31 on: July 28, 2011, 07:33:38 PM »
Quote
Oxygen can emit a machine script for the memory image but not for the PE file itself.
Im not expert but i see that old LibryCompiler written in VB 6.0 can create directly PE file.

I think you misunderstood.

Charles talked about different source code files - all part of Oxygen.

The LibryCompiler has different files like assembler, linker etc. as well.


BTW: The LibryCompiler creates a "Hello World!" executable with 2560bytes.  :P

« Last Edit: July 28, 2011, 08:28:36 PM by efgee »

Charles Pegge

  • Guest
Re: O2 Source ?
« Reply #32 on: July 28, 2011, 10:07:09 PM »
It depends on how many sections are used. Each section is padded out to the nearest 512 bytes, and when loaded into memory, these sections are aligned to the nearest 4K bytes.

The smallest storage unit on disk is 4K.

I think the only way to get an indication of a file's actual content is to Zip it. (about 1K in this case).

Charles

JRS

  • Guest
Re: O2 Source ?
« Reply #33 on: July 28, 2011, 10:46:08 PM »
Quote
Normally you never see it so it is quite a shock when all the opcodes and link information is made visible


Aurel

  • Guest
Re: O2 Source ?
« Reply #34 on: July 29, 2011, 12:18:56 AM »
Quote
The LibryCompiler has different files like assembler, linker etc. as well.

Where you see assembler in Libry source code ???
There is only pure machine hex code...

Peter

  • Guest
Re: O2 Source ?
« Reply #35 on: July 29, 2011, 01:55:06 AM »
  LOL

  :D  :D   :D

Aurel

  • Guest
Re: O2 Source ?
« Reply #36 on: July 29, 2011, 05:09:36 AM »
LOL 2
 :D :D :D

efgee

  • Guest
Re: O2 Source ?
« Reply #37 on: July 29, 2011, 10:44:41 AM »
Quote
The LibryCompiler has different files like assembler, linker etc. as well.

Where you see assembler in Libry source code ???
There is only pure machine hex code...

Well, every time you see stuff like:

AddSectionByte(...
AddSectionWord(...
AddSectionDWord(...

hex numbers are added to different arrays that hold the information for different sections.

If you see stuff like:
AddSectionByte($58, ES_CODE)
you know that this function adds $58 to the program code section.

If we go on with this example if you see in an assembler code stuff like:
pop eax
the assembler adds $58 to the code section (only valid for the intel processors).

As you can see "pop eax" in assembler is the same as AddSectionByte($58, ES_CODE) in the LibryCompiler source code.

So if somebody knows what he is doing it's pretty straight forward... and a lot of work.
« Last Edit: July 29, 2011, 10:59:17 AM by efgee »

JRS

  • Guest
Re: O2 Source ?
« Reply #38 on: July 29, 2011, 02:46:01 PM »
Is there a section of O2 binary executable code that is static and in all executables that I could just stitch into the final cut?

Charles Pegge

  • Guest
Re: O2 Source ?
« Reply #39 on: July 29, 2011, 08:24:20 PM »

No, I don't think it would help. There are too many mappings. The best way to test the code initially would be to create a program for viewing the hexadecimal byte output. Then run some very simple test scripts to exercise each instruction.

I reckon testing is by far the greatest task in program development, and the earlier you can test something the easier it is.

Charles

JRS

  • Guest
Re: O2 Source ?
« Reply #40 on: July 29, 2011, 09:51:05 PM »
Talk about taking a leap of faith ...

If I didn't think I might learn something in my journey to being overwhelmed, I would admit this is over my head an move on.

It might be fun trying though.  8)

Quote
The best way to test the code initially would be to create a program for viewing the hexadecimal byte output.

Is the first task on the list to convert THIS.



RADARE

Quote
The project aims to create a complete, portable, multi-architecture,
 unix-like toolchain for reverse engineering.

It is composed by an hexadecimal editor (radare) with a wrapped
IO layer supporting multiple backends for local/remote files,
debugger (osx,bsd,linux,w32), stream analyzer, assembler/disassembler
(rasm) for x86,arm,ppc,m68k,java,msil,sparc code analysis modules and
scripting facilities. A bindiffer named radiff, base converter (rax),
shellcode development helper (rasc), a binary information extracter
supporting (pe, mach0, elf, class, ...) named rabin, and a block-based
hash utility called rahash.

This package contains the gtk enabled edition of radare.

Code: [Select]
jrs@laptop:~$ radare -h
radare [options] [file]
  -s [offset]      seek to the desired offset (cfg.seek)
  -b [blocksize]   change the block size (512) (cfg.bsize)
  -i [script]      interpret radare or ruby/python/perl/lua script
  -p [project]     load metadata from project file
  -l [plugin.so]   link against a plugin (.so or .dll)
  -e [key=val]     evaluates a configuration string
  -d [program|pid] debug a program. same as --args in gdb
  -f               set block size to fit file size
  -L               list all available plugins
  -w               open file in read-write mode
  -x               dump block in hexa and exit
  -n               do not load ~/.radarerc and ./radarerc
  -v               same as -e cfg.verbose=false
  -V               show version information
  -u               unknown size (no seek limits)
  -h               this help message
jrs@laptop:~$ radare -L
haret       Read WCE memory ( haret://host:port )
shm         shared memory ( shm://key )
mmap        memory mapped device ( mmap://file )
serial      serial port access ( serial://path/to/dev:speed )
debug       Debugs or attach to a process ( dbg://file or pid://PID )
malloc      memory allocation ( malloc://size )
remote      TCP IO ( listen://:port or connect://host:port )
winedbg     Wine Debugger interface ( winedbg://program.exe )
windbg      Windbg serial port debugger ( windbg:///path/to/socket )
socket      socket stream access ( socket://host:port or socket://./socket.file )
gxemul      GxEmul Debugger interface ( gxemul://program.arm )
bfdbg       brainfuck debugger
gdbwrap     Connect to remote GDB using eresi's gdbwrap (gdbwrap://host:port)
gdb         Debugs/attach with gdb (gdb://file, gdb://PID, gdb://host:port)
gdbx        GDB shell interface 'gdbx://program.exe args' )
posix       plain posix file access
jrs@laptop:~$

Screen Shots

Code: [Select]
jrs@laptop:~/.wine/drive_c/o2h/A36$ radare Oxygen.dll
open ro Oxygen.dll
Generating default ~/.radarerc...
> Importing file information...
[Information]
class=PE32
dll=True
machine=i386
big_endian=False
subsystem=Windows CUI
relocs=False
line_nums=True
local_syms=True
debug=True
number_of_sections=8
baddr=0x10000000
section_alignment=4096
file_alignment=512
image_size=6721536
[Entrypoint]
Memory address: 0x100010c0
> Importing symbols...
8 sections added
TODO
63 imports added
20 symbols added
4096 strings added
0
0
> Analyzing code...
                                                                        
strings: 2398
functions: 445
structs: 0
data_xrefs: 1199
code_xrefs: 1379
[0x100010C0]>
« Last Edit: July 30, 2011, 09:17:33 AM by JRS »

Aurel

  • Guest
Re: O2 Source ?
« Reply #41 on: July 30, 2011, 01:41:05 AM »
Quote
the assembler adds $58 to the code section (only valid for the intel processors).
ooups i don't know that...
Anyway Libry is not bad example how write native compiler,right?

Charles Pegge

  • Guest
Re: O2 Source ?
« Reply #42 on: July 30, 2011, 03:27:05 AM »
Radare is new to me John. Very interesting.

Here is a piece of code for testing your linker binary output. The first function displays the file in hexadecimal bytes. The second function executes the program directly in memory, bypassing all that PE stuff.

To demonstrate, a program written in machine code is generated. It is six bytes long and returns the long integer 0x1234

putfile "t.bin", chr(0xb8) chr(0x4) chr(0x3) chr(0x2) chr(0x1) chr(0xc3)

Code: OxygenBasic
  1.  
  2.   'Create a prog for direct call in mem
  3.  '====================================
  4.  
  5.  
  6.   putfile "t.bin", chr(0xb8) chr(0x4) chr(0x3) chr(0x2) chr(0x1) chr(0xc3)
  7.  
  8.   '====
  9.  
  10.   string prog=getfile "t.bin"
  11.  
  12.   function display(string prog)
  13.   '============================
  14.  sys a,c,i
  15.   string cr=chr(13)+chr(10)
  16.   string pr="Program Bytes" cr cr
  17.   '
  18.  for i=1 to len prog
  19.     a=asc prog,i
  20.     pr+=mid ("0"+hex(a),-2) " "
  21.     c+=1
  22.     if c>16 then pr+=cr : c=0
  23.   next
  24.   '
  25.  print pr
  26.   end function
  27.  
  28.  
  29.   function exec(string prog)
  30. '=========================
  31.  '
  32.  sys v=call ?prog
  33.   print "Result: 0x" hex v
  34.   '
  35.  end function
  36.  
  37.  
  38.   display prog
  39.   exec prog
  40.  
  41.  

Charles
« Last Edit: July 30, 2011, 04:13:31 AM by Charles Pegge »

Peter

  • Guest
Re: O2 Source ?
« Reply #43 on: July 30, 2011, 04:46:45 AM »
Code: [Select]
pr+=mid ("0"+hex(a),-2) " "
pr+=asc ("0"+hex(a),-2) " " 

Charles Pegge

  • Guest
Re: O2 Source ?
« Reply #44 on: July 30, 2011, 05:00:34 AM »

The intention is to produce hex byte codes  padded with a leading 0 to display consistent 2 character codes:

B8 04 03 02 01 C3

Charles