Spørgsmål:
Henter kryptering / kodningslogik fra dll
leepfrog
2014-01-26 19:53:41 UTC
view on stackexchange narkive permalink

Jeg prøver at hente en dekrypterings- / dekonteringslogik fra et program. Desværre har jeg stort set ingen erfaring med reverse engineering.

Jeg bygger en alternativ controller-applikation til en multimedieenhed. Den originale controller er tilgængelig til Windows (som jeg målretter mod) samt til mac, ios og android .Det meste af kommunikationen mellem enheden og controller-applikationen ligner UPnP-protokollen, derved overføres i XML og kan læses i klar tekst. Der er dog en forekomst, hvor enheden sender en slags token til controlleren (som controlleren bruger derefter for at godkende mod andre tjenester) og denne transmission synes at være kodet / krypteret / tilsløret (kaldet "kodet" i teksten). Denne kodede form transmitteres i et XML-felt med et normalt UPnP-svar.

Jeg har foretaget følgende observationer, mens jeg overvåger flere transmissioner af den kodede form:

  • Det starter altid med 2: og efterfølges af, hvad der synes at være en base64-kodet streng
  • Ved transmission flere t imes stingændringerne, selvom indholdet angiveligt ikke ændrede sig (dette antages at ingen andre variabler som et tidsstempel er inkluderet før kodning). Så en slags salt kunne være til stede.
  • Strengens længde forbliver den samme, hvis dataene ikke ændres
  • Hvis du fjerner alle tokens fra controlleren, er der stadig nogle kodede data transmitteret i dette felt. Dette får mig til at tænke, at enten polstring finder sted, eller (mere sandsynligt) afkoder den kodede streng til noget, der er serialiseret fra datastrukturen (måske endda XML).
  • Tokenet, der bruges til godkendelse (så dekodet form) forbliver den samme, selvom den kodede version er forskellig.

Selve applikationen er skrevet i c # men alle de sikkerhedsrelaterede ting (inklusive afkodning / håndtering af tokenet) ser ud til at blive kaldt ved hjælp af pINVOKE fra en DLL, som ikke var skrevet i .net .

Jeg løb tegnrch på dll, hvor jeg formoder, at kodningen skal finde sted, men mange mulige hits returneres (30+). Når man ser på dll, ser det ud til, at openssl-biblioteket er samlet i det, så der kan være mange falske positive. DLL'en håndterer også HTTPS-kommunikation, så openssl er ikke nødvendigvis relateret til den kodningsmetode, jeg leder efter.

Jeg har forsøgt at undersøge ida pro og windbg, men det jeg læser fra tutorials drejer sig hovedsageligt om indstilling breakpoints før du klikker på en knap, der aktiveres f.eks dog i mit tilfælde modtager controller-applikationen disse data en gang ved applikationsstart (med snesevis af andre UPnP-pakker) og mit gæt er, at afkodning finder sted ved modtagelse af pakken, så der er ingen mulighed for at indstille et brudpunkt til f.eks. Hvad jeg dog kunne finde ud af, er at de afkodede tokens er til stede i hukommelsen (dog forskydninger varierer hver gang applikationen startes). Den kodede version ser ikke ud til at være til stede i hukommelsen under kørsel.

Nogle eksempler: Kodet streng, når der ikke er konfigureret et token:

  2: nrlrLkCeoSOK34YSDZUKzbXs6olm9YSE4jLFnXONMJO5XhjfwCsPpm > 

Tre strenge repræsenterer (angiveligt) de samme data:

  2: PITkxbk12KlLvsPtOV8ptZbqfMcK0EmSA / XOejbBHs8 + ffKNzwYSoz6oGdL5wiudTWJri4ZG / CwB2 / Pfh91ULuqBYWaLaW7YCzEzRb53NS + qarNiUAU0Kn7TCuhPzougX91sKFOP3BTWdUu6BQBP7IlWIZ1odp4ilU8RdEUhPvkOVyH9OBQwvpYXPbqca / OLGjNFPvomS5yaeOjtbpDuVd8mfvBycVHB8rULDvkJcXOS / qQWHOt8iYYZXHBXBD9v4h3Bs + o09sWsXxIh + 0q4qz + TKY / gYRnogenJ9vN83lkE6FTgtHns / 6zxlCt4xaFINmShdovvYlS / SDZ + aKgcGoq8zFjWJAbc2WQQwdxPTLZsCUmJSjH6jp1t6pCv7t4tBMaSpCTvAoRrXElNQIW1LOe / 9X6Cu5Ggjp17Whwe9 + 7DuWz6HxPEpq / TIVLIV7kJQRj6GcD7 / sWPakLLXxiN1Bf5yfJVvX3wA67vwXwigO5v5d5JzKPrjULskeCLUk // 61gPulxFguf63cn6NN1zXpDBOf3sCxwzquKIobE8s + F2mJ0pzWCNwYSg3IpvAUzH2fqLvsjqO6DdNr6AVZr77vPG9 / DQ2 + sFesFHMFQ859eVwNUSvYkxQoqFukxJOXfY + muf1AYqczvCA0K / uYDnKAj24oB0Wgw9YvA S8YHO9YI =
2: XfaIk9XLov9k8vHKXXZ9NFpUvNSk8QsEjI73E + txW6wg + kSr2hWWljLU5OOmQBcN + ACRKF4f4paJBxlf9AGiFnWyrNKT4nguM / 4iBsHsiIADlMavjYncsNntClcxPh + Me2l1W / uQzqG83SlHcM525P5wfpH45zC7 / hFjmWKPGIQ / k / LAsJy6gZlrmOZ0B2JJ0Cw + yUOzTD4EUo092EPRf7hq7aIrs0dLfPtT2D6LMKwmKAfW2fhllV / jJ33dAVn6Dy / PctFErGtvXljhnuI8r5qpMyIOZ5SsoFE / TNK + kOqWYVg5 / djbls / fpV2p70B9vxzpVkko8pfIJ3UmYsqu5WSlaX441Qs / gY8nzjWmJw8 + 8LzxL + P2YgYo5W + u6a / oS4R + sZ3FD0q3KQvmVNjklgdGipTOfsv9amP6M6ifAHPdgB5kj9ivOtufaiFKR9GqS9 / g4vjYQqofU3Yk2nB6xMi2W1eA2Mk + BJAjfsTr1Yo4Njoa0 + XQfAMfqpJe9Zka2NSLu2noDDEdRTqASJi6IiNxbsbsVGHhHFEAEojwTQlrk6xUtOt5RjTA6XovdgQoGywjU + FixEbEEQA0TbNE2KsFhmKXIauo3yQaZ9EKDMJjOMz53UK / EFEZu6L7yy7ijnQB13rSw + obIbFXr / J / vxc97EsRXm7zSUIQoEq9qwKE = 2: 9xVbeGOq4XDN26aIYcbNVYDAVQNgVseVvipidY71ZzJAKYlYdcDd46uIFQdfla5pXqupZABtl4Njg + wC8lxmxx2EFR1ZwBYr + ZbvswCQp9YKKMAhI3Ly12j3XNrtIAfl + EDDgz5woHNLXLfVthFel4WSe3mGHMa0S8ZcXRyRyLJHx7lIXZ4G68by2cLTYTldAWuYYl7xhmIJNLgMA8iI63FBGYiw / Testamente / 30KkLPoUP7As1R / GfItnDfp0pG5l63DtBFSo3mnDRVrdDIsYALRpsBLhhvx4 + 0CjlyMaK511pM0 + IxmtcE6L0L6 QhcztYzWcjnbjkLi7r9dmO5ABEfq8 / 8 + wpnxERXwiwRTsYPy2 / + rYQlLK0hkeGiqacbnjQQWyVRVzaE47oAhC9ln ws5go / c + + reDHhmpf / 9vj9RO7EzFq9LVZRxbxy7C5QZzHEqncSdR + TzOrs0MkRO3pe + e2Q5P68kgTYVO6K8XpvLU9ClfDyIOCpwNufRz / fEVl2ry5UrjS5d5k39 UheQizu9nu + Y + + + 4xC42Wd y1E7WsZYQaLgNL6EQP1w8yb3 + PwdvgOxgId7IMag81 / 4 + mjO9x / N1Zoq405nSXodirZ5RiWIAl4 + uHARqwDnX1lZQo7Fo0pMs8ZwOtGiqA8 / WVbMKqigBOEW6m2 / 2K2nI3cTYKqmVg =  / pre> 

Jeg vil meget gerne høre forslag til, hvordan man løser dette problem for at få mere indsigt.

Forsøgte du at dekompilere .net-delen? Er det tilsløret?
Jeg kan åbne .net-delen med dotPeek uden problemer. Problemet er, at modtagelse / afkodning og brug af strengen håndteres fuldstændigt i ikke -.net-DLL'en
To svar:
Sigtran
2014-01-27 15:57:56 UTC
view on stackexchange narkive permalink

Kan ikke kommentere, så det er et svar :)

- Hvis du ved, hvad dll det er, skal du se på, og det er skrevet i .net, vil IDA sandsynligvis ikke være den bedste mulighed ( fra personlig erfaring).

Hvis du dog stadig er på udkig efter en dll, som du har brug for at dekompilere, vil du måske give APImon og indkalde et skud for at finde ud af, hvad der nøjagtigt skal dekompileres. > Jeg vil foreslå, at du prøver at bruge en .net-dekompiler, f.eks. dotPeek eller andre. Du kan generelt læse koden, som den er fra ethvert .net-program (ikke tilsløret / krypteret) Hvis en dll er tilsløret, kan du prøve at fjerne dem fra dem med de4dot eller dumpe fra hukommelsen og analysere det i stedet.

Ovenstående strenge er bestemt base64 kodet, så du vil sandsynligvis være på udkig efter object.binary.base64

Undskyld, jeg gjorde det ikke klart. Det generelle program er skrevet i .net, som jeg allerede kiggede på med dotPeek. Men alt relateret til modtagelse af den kodede streng, afkodning af den og brug af den til godkendelse mod fjerntjenesten sker i ikke -.net DLL. Fra min analyse ser det ud til, at den afkodede streng aldrig forlader denne DLL.
Fik det :) Jeg ville starte med at se på eksporten af ​​denne dll for at se, om navnene ville være suggestive nok og gøre en smule googling på disse. Du kan muligvis også sende den krypterede streng som en parameter til en dll-eksport (prøv ollydbg) og fejle igennem den for at se det hele i drift.
Mick
2014-03-30 04:43:50 UTC
view on stackexchange narkive permalink

Se på plugin til IDA Pro kaldet IDA Scope. Den har en kryptoidentifikationsfacilitet, som jeg tror vil hjælpe dig.

enter image description here



Denne spørgsmål og svar blev automatisk oversat fra det engelske sprog.Det originale indhold er tilgængeligt på stackexchange, som vi takker for den cc by-sa 3.0-licens, den distribueres under.
Loading...