NSOs have more invalid than correct instructions

[GovanifY]

Work environment

Questions	Answers
OS/arch/bits (mandatory)	Gentoo AMD64
File format of the file you reverse (mandatory)	NSO(Nintendo Switch)
Architecture/bits of the file (mandatory)	ARM(64)
r2 -v full output, not truncated (mandatory)	radare2 2.3.0-git 16958 @ linux-x86-64 git.2.2.0-167-g442753799 commit: 4427537998bac1914422121ae7424f780bd07c22 build: 2018-01-08__16:21:11
r2 -V full output in a pastebin document (mandatory)	https://ghostbin.com/paste/3j42p

Expected behavior

Do not have a majority of invalid operations in the analyzed code

Actual behavior

Have a majority of invalid operations in the code

Steps to reproduce the behavior

Analyze any NSO for the Nintendo Switch, here is an overview of what I mean by a majority: https://asciinema.org/a/OYrWGgkttGaAfQKL3YGgxFV5D

Additional Logs, screenshots, compiled binaries, source-code, configuration dump, ...

There is a working parser available for IDA here producing generally great result: https://github.com/reswitched/loaders/blob/master/nxo64.py It might also be an issue related to capstone as I had several issues with capstone in the past, especially on MIPS3 and ARM Here is the binary I've shown in the asciinema, the IDA loader referenced above parses it correctly(and optionally finds some nifty symbols) main.zip

[radare]

cc @RKX1209

[radare]

i doubt this is a problem in capstone, its more probably that sections are wrongly loaded, so translating this python code into C should be the way to go. see the nso.c if you want to contribute.

I dont have any Switch or time/prio to do that right now, so if you want to contribute you are welcome.

Also, is this binary shareable? can we put it in the radare2-regressions repo or is there any kind of copyright issue? thanks

[GovanifY]

I don't think you could put it in radare2-regressions but you could always try to craft one using this tool As for capstone I said it could be an issue as I've hit similar issues in the past. I will look at the nso loader asap

[radare]

here’s the code

https://github.com/radare/radare2/blob/master/libr/bin/p/bin_nso.c https://github.com/radare/radare2/blob/master/libr/bin/p/bin_nso.c

On 8 Jan 2018, at 17:50, GovanifY notifications@github.com wrote:

I don't think you could put it in radare2-regressions but you could always try to craft one using this tool https://github.com/switchbrew/switch-tools/blob/master/src/elf2nso.c As for capstone I said it could be an issue as I've hit similar issues in the past. I will look at the nso loader asap

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/radare/radare2/issues/9152#issuecomment-356023582, or mute the thread https://github.com/notifications/unsubscribe-auth/AA3-lh67k7gNxGfrePv6qFqri5k7IO-Qks5tIkc7gaJpZM4RWjcO.

[radare]

the arm64 disassembler works fine for ios, android binaries, so my guess is that it is trying to disassemble data instead of code because of the sections being wrong.

On 8 Jan 2018, at 17:50, GovanifY notifications@github.com wrote:

I don't think you could put it in radare2-regressions but you could always try to craft one using this tool https://github.com/switchbrew/switch-tools/blob/master/src/elf2nso.c As for capstone I said it could be an issue as I've hit similar issues in the past. I will look at the nso loader asap

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/radare/radare2/issues/9152#issuecomment-356023582, or mute the thread https://github.com/notifications/unsubscribe-auth/AA3-lh67k7gNxGfrePv6qFqri5k7IO-Qks5tIkc7gaJpZM4RWjcO.

[RKX1209]

@GovanifY Hi. You need to add '-e io.cache=true' to r2 because NSO loader decompress packed binary at loading time:)

[GovanifY]

@RKX1209 It indeed fixed the issue, but shouldn't we document that/enable it when loading the NR/SO module?

[RKX1209]

@GovanifY Yeah. That's true. Hmm.. Where should I document about it? > @radare

[Maijin]

Maybe you can do like some plugin and eprintf that when opening the NR/SO module?

[Maijin]

See https://github.com/radare/radare2/blob/master/libr/bin/p/bin_elf.c#L66 or even https://github.com/radare/radare2/blob/master/libr/bin/p/bin_bf.c#L47

[RKX1209]

OK. I'll send patch later.

[radare]

The eprintf is a nice workaround but we shoukd improve the iocache and allowing bin plugins to set this option for a specific range or fd will be good.

Feel free to contribute on that change too

On 8 Jan 2018, at 19:58, Ren Kimura notifications@github.com wrote:

OK. I'll send patch later.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[RKX1209]

OK. I just added notice message when opening the NSO without io.cache option.

[radare]

Closing this for now. I plan to redesign some aspects of rbin to allow plugins determine if the i should be cached when loading or not. But first i have to optimize the cache system because irght now its o(n) and it doesnt scales.

As long as nso files gives you the hint to solve the problem, im considered as solved