[an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] (none) [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] (none) [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive]
 
[an error occurred while processing this directive] [an error occurred while processing this directive]
Skåne Sjælland Linux User Group - http://www.sslug.dk Home   Subscribe   Mail Archive   Forum   Calendar   Search
MhonArc Date: [Date Prev] [Date Index] [Date Next]   Thread: [Date Prev] [Thread Index] [Date Next]   MhonArc
 

Reverse engineering af driver kode



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hej

Jeg er ved at prøve at finde hoved og hale i en binær driver til en
SRAM chip for at kunne emulere den, og det går egentlig overraskende
godt, men jeg er så stødt på et problem med noget kode, som jeg ikke
kan gennemskue meningen i.
Nedenstående er ikke den fulde disassembly listning, men alt frem til
den blok, som jeg ikke forstår. Det er blokken med labelen
'magic_happens', som jeg ikke forstår:

;Prototype:
;   size_t sram_write(struct file *file,        <-- Passed in EAX
;                     const char __user * data, <-- Passed in EDX
;                     size_t len,               <-- Passed in ECX
;                     loff_t * offset)          <-- Passed as first
stack variable

;Set up stack frame
push   ebp
mov    ebp, esp
sub    esp, 14h

;Now EBX, ESI and EDI are stored.
;They are restored before returning from this function
mov    [ebp-0ch], ebx    ;Save EBX for later restoration
mov    [ebp-08h], esi    ;Save ESI for later restoration
mov    [ebp-04h], edi    ;Save EDI for later restoration

;Now make sure that write does not extend available size
mov    eax, ds:size      ;'ds:size' contains total size of memory
mov    edi, [ebp+8]      ;Put 'offset' into EDI
mov    [ebp-10h], edx    ;Store 'data' pointer
mov    esi, [edi]        ;Read low 32 bits offset into ESI (high 32
bits are ignored)
sub    eax, esi          ;EAX = ds:size - *offset = Space left in
memory relative to offset
cmp    eax, ecx          ;Compare space left to 'len'
mov    ds:aux_pos, eax   ;Store space left
jb     short too_short   ;If len > space left go to too_short

magic_happens:
mov    edx, esp          ;Put stack pointer into EDX
mov    ebx, ecx          ;Put 'len' into EBX
mov    eax, [ebp-10h]    ;Put 'data' pointer into EAX
and    edx, 0ffffe000h   ;???? WHY ?????
add    eax, ebx          ;EAX = data + len = end of data
sbb    ecx, ecx          ;Subtract with borrow...WHY ????
cmp    [edx+18h], eax    ;Compare obscured address with end of
data...WHY ??
sbb    ecx, 0            ;???
test   ecx, ecx          ;Set flags for ECX...but why ??
jnz    short err1

;HER SKER SELVE SKRIVNINGEN SÅ...IKKE SÅ INTERESSANT FOR MIT PROBLEM

err1:
mov    [esp], offset str2;Format string: "<4>Cannot read from
write-call-buffer\n"
xor    ebx, ebx
call printk
jmp    short end

too_short:
mov    [esp], offset str1;Format string on stack: "<4>Limiting write
to available memory\n"
call    printk
mov    ecx, ds:aux_pos   ;Put available memory size into ECX
jmp    short magic_happens

end:
mov    eax, ebx        ;Set return value
mov    esi, [ebp-08h]  ;Restore ESI
mov    ebx, [ebp-0ch]  ;Restore EBX
mov    edi, [ebp-04h]  ;Restore EDI
;Tear down stack frame
mov    esp, ebp
pop    ebp
ret


Det er en char device driver, og ovenstående implementerer 'write'
funktionen i en 'struct file_operations'.
Jeg vil mene, at følgende sammenligner returadressen med EAX:
mov    edx, esp
cmp    [edx+18h], eax

...da der ligger en EBP og 14h lokale variable på stakken. Men der er
så lige den der AND operation indimellem:
mov    edx, esp
and    edx, 0ffffe000h
cmp    [edx+18h], eax

Hvad sker der lige der ?
Og hvad skal de to SBB instruktioner gøre godt for ?

Nogen der kan knække nødden ?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2g+OQACgkQzDMeisFqGZZ/4ACcDEMq7wGSlBQKDxROVAYASRbv
9R4AnjpuhyPG2a3C8Af3r+CAetpmFxOS
=T6V8
-----END PGP SIGNATURE-----



 
Home   Subscribe   Mail Archive   Index   Calendar   Search

 
 
Questions about the web-pages to <www_admin>. Last modified 2011-05-01, 02:01 CEST [an error occurred while processing this directive]
This page is maintained by [an error occurred while processing this directive]MHonArc [an error occurred while processing this directive] # [an error occurred while processing this directive] *