flat assembler
Message board for the users of flat assembler.

flat assembler > DOS > Strange 16bit second stage bootstub (possibly ex bz loader?)

Author
Thread Post new topic Reply to topic
dstyl



Joined: 23 Jul 2015
Posts: 58
Im currently trying to boot an uefi emulation for bios based systems(duet) on an x86 based smartphone.
So i disassembled a file in a custom kernel called second.bin, which turns out
to be regular real mode code (16bit). Which i guess means that there is a complete
bios available, since there is no such thing as an 16bit uefi.
Which matches the info from http://newandroidbook.com/Articles/aboot.html
The code ive got looks nothing like a linux loader. The kernel is in executable bZimage.

Code:
; Format      : Binary file
; Base Address: 0000h Range: 0000h - 2000h Loaded length: 00002000h

                .686p
                .mmx
                .model flat

; Segment type: Pure code, assume cs:seg000
; assume es:nothing, ss:nothing, ds:nothing, fs:nothing, gs:nothing
                 cld                     ; clears flag
                 cli                     ; halts all interrupts
                 mov     sp, 0           ; set stackpointer to zero???
                 lock adc al, ch         ; locks mem adress to atomic, then store result in al
                 push    3               ; pushes 3 to the stack
                 add     [bp+di+18h], bh ; stores upper 8bits of bp + ? to bp?+di?+24
; ---------------------------------------------------------------------------
;tons of db dup data stuff, at segment 0:48 (in hex) its followed by one instruction
                 add     [di+27BCh], cl  ; stores value of cl + ? in di+10172
                                                      ;(far beyond size of the bin (8kb)
;again tons of db dup stuff
;then some strings that arent referenced again any where
aBootstubVersio db 'Bootstub Version: 1.4 ...',0Ah,0
                        db 'capfreq=',0
                        db 'Using bzImage to boot',0Ah,0
aJumpToKernel32 db 'Jump to kernel 32bit entry',0Ah,0
                 align 4
aFatalErrorTocS db 'FATAL ERROR: TOC size is too large for IMR',0Ah,0
aFatalErrorVxeF db 'FATAL ERROR: VXE FW image size is too large for IMR',0Ah,0
                        align 4
aFatalErrorSpsI db 'FATAL ERROR: SPS image size is too large for IMR',0Ah,0
                        align 4
aFatalErrorXenI db 'FATAL ERROR: Xen image size is too large for IMR',0Ah,0
                        align 4
aRelocatingInit db 'Relocating initramfs to high memory ...',0Ah,0
                        align 4
aWonTRelocateIn db 'Won',27h,'t relocate initramfs, are you in SLE?',0Ah,0
                        align 2
 aUsingMultiboot db 'Using multiboot image to boot',0Ah,0
                        align 2
 aBootstubSfi_ad db 'Bootstub: sfi_add_e820_entry failed',0Ah,0
                        align 4
 aBootstubSfi_se db 'Bootstub: sfi_setup_mmap failed',0Ah,0
                        align 4
 aBootstubSfiMma db 'Bootstub: SFI MMAP table not found',0Ah,0
 aBootstubMapSfi db 'Bootstub: map SFI MMAP to e820 table',0Ah,0
                        align 4

    

My Question is could i just write my own 16bit asembly stub to switch to long mode and then set the stack pointer to the beginning of the uefi to get executed.
As i understand in 16bit mode there is only one priviliege level that is ring0.
And does 16bit code indicate a bios based boot environment?
Also what does setting the stackpointer to zero in the second.bin file?

Thanks in advance.
Post 18 Jun 2018, 21:25
View user's profile Send private message Reply with quote
alexfru



Joined: 23 Mar 2014
Posts: 63
That "lock adc" looks odd. Did you disassemble the code as 32-bit whereas it should've been 16-bit?
Post 19 Jun 2018, 04:40
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15982
Location: Qo'noS
The disassembly is not correct. You night want to try putting your disassembler into 32-bit mode and check that you are not decoding some header information.
Post 19 Jun 2018, 05:06
View user's profile Send private message Visit poster's website Reply with quote
dstyl



Joined: 23 Jul 2015
Posts: 58
Thanks a lot for the help, you were right its a 32 bit binary.
As i understand it, the bin checks some stuff if everything is passed it jumps to the loc_B35
subroutine which loads the kernel. sub_32a does the screen stuff.

Code:
loc_B35:                                ; CODE XREF: sub_374+799j sub_374+7A9j
                lea     eax, (aJumpToKernel32 - 1708h)[ebx] ; "Jump to kernel 32bit entry\n"
                mov     [esp+4Ch+var_4C], eax
                call    sub_32A
                mov     eax, esi
                lea     esp, [esp+3Ch]
                pop     ebx
                pop     esi
                pop     edi
                pop     ebp
                retn
    

my guess would be that this is the print routine.
Code:
; =============== S U B R O U T I N E =======================================


sub_32A         proc near               ; CODE XREF: sub_374+C3p sub_374+DDp ...

var_1C          = dword ptr -1Ch
arg_0           = dword ptr  4

                push    ebx
                lea     esp, [esp-18h]
                call    sub_10D0
                add     ebx, 13D4h
                cmp     dword ptr ds:1100408h, 0
                jnz     short loc_36E
                mov     eax, ds:110040Ch
                cmp     eax, 1
                jz      short loc_354
                cmp     eax, 2
                jz      short loc_362
                jmp     short loc_36E
; ---------------------------------------------------------------------------

loc_354:                                ; CODE XREF: sub_32A+21j
                mov     eax, [esp+1Ch+arg_0]
                mov     [esp+1Ch+var_1C], eax
                call    sub_F90
                jmp     short loc_36E
; ---------------------------------------------------------------------------

loc_362:                                ; CODE XREF: sub_32A+26j
                mov     eax, [esp+1Ch+arg_0]
                mov     [esp+1Ch+var_1C], eax
                call    sub_F11

loc_36E:                                ; CODE XREF: sub_32A+17j sub_32A+28j ...
                lea     esp, [esp+18h]
                pop     ebx
                retn
sub_32A         endp
    

Seeing the disassembly i would like to ask if it possible to just far jump(static) to the adress where the os/bin/etc that i want to get executed by using
Code:
push 0x8000
ret
    

?
Post 20 Jun 2018, 19:16
View user's profile Send private message Reply with quote
dstyl



Joined: 23 Jul 2015
Posts: 58
alexfru wrote:
That "lock adc" looks odd. Did you disassemble the code as 32-bit whereas it should've been 16-bit?

Thanks a lot, the disassembler found the instruction even though it was set to 16bit mode Very Happy .
Post 20 Jun 2018, 19:21
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15982
Location: Qo'noS
dstyl wrote:
Seeing the disassembly i would like to ask if it possible to just far jump(static) to the adress where the os/bin/etc that i want to get executed by using
Code:
push 0x8000
ret
    

?
That is a near jump equivalent because it doesn't load the CS register. If you want a far jump then you can also push the new CS value and use RETF. But make sure your encoding is correctly set to 32-bit mode when you assemble.
Post 20 Jun 2018, 19:33
View user's profile Send private message Visit poster's website Reply with quote
dstyl



Joined: 23 Jul 2015
Posts: 58
Thanks for the advice. im having trouble reassembling the img but i will post here again when i got the img booting.
Post 21 Jun 2018, 21:28
View user's profile Send private message Reply with quote
dstyl



Joined: 23 Jul 2015
Posts: 58
I managed to rebuild the boot.img and to flash it.
The phone doesnt reach the linux kernel, so my code is definetly wrong or the kernel just doesnt start
with the missing parameters.
Code:
use32          ; use 32-bit code

;print subroutine placeholder
push 10008000h;jmp to linux kernel
ret
    

I will have to change the following parameters to the right values.
Code:
kernel=kernel
ramdisk=ramdisk
second=second.img
page_size=2048
kernel_size=6999792
ramdisk_size=5143170
second_size=8192
base_addr=0x10000000
kernel_offset=0x00008000
ramdisk_offset=0x01000000
tags_offset=0x00000100
    

And as i understand if i add org 10000000h
the second.img will be loaded then at 0x10000000:10000000 .
so it wouldnt help or?
also since i dont know how to set the cs register right so,
i would like to try something similar to this.
Code:
jmp [executable]

executable dw 10008000h
    

I will try to use the disassembled print routine from the custom kernel so
text debuging would be possible.
Please excuse my noob questions, ive only programmed assembly stuff that used c stdlib
and im also a beginner.


Last edited by dstyl on 24 Jun 2018, 14:07; edited 1 time in total
Post 24 Jun 2018, 14:05
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15982
Location: Qo'noS
If you are using push as a jump alternative with both CS and IP then you need to use RETF..
Post 24 Jun 2018, 14:06
View user's profile Send private message Visit poster's website Reply with quote
dstyl



Joined: 23 Jul 2015
Posts: 58
Thanks for your help i will try if it works using retf and cs and ip.
Post 24 Jun 2018, 14:09
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15982
Location: Qo'noS
You can also use jmp far [...]. It might make the code more understandable.
Post 24 Jun 2018, 14:12
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2018, Tomasz Grysztar.

Powered by rwasa.