1

I'm trying to patch a binary using the instructions provided at this answer.

Initial setup:

wget https://f000.backblazeb2.com/file/altstore/altserver/1_4_1.zip
unzip 1_4_1.zip

This program basically downloads and ipa file, signs it and pushes it into my iPhone. And my main goal is to change this program to load their beta version of the same instead so I'm doing this:

strings -o -t d ~/Desktop/AltServer.app/Contents/MacOS/AltServer | grep ipa

And I get:

450486 Unzipping .ipa...
455808 https://f000.backblazeb2.com/file/altstore/altstore.ipa
455872 Failed to remove downloaded .ipa.

So clearly, the URL to download the ipa file is at offset 455808. I try patching this using the instructions provided by the Stackoverflow answer mentioned above:

printf "https://f000.backblazeb2.com/file/altstore/altstore-beta.ipa" > tmp
dd if=tmp of=~/Desktop/AltServer.app/Contents/MacOS/AltServer obs=1 seek=455808 conv=notrunc

And it writes in the binary code with output:

0+1 records in
60+0 records out
60 bytes transferred in 0.001586 secs (37832 bytes/sec)

However, when I run strings again, the URL is set at some other location like:

$ strings -o -t d ~/Desktop/AltServer.app/Contents/MacOS/AltServer | grep ipa
439424 https://f000.backblazeb2.com/file/altstore/altstore-beta.ipa
450486 Unzipping .ipa...
455808 https://f000.backblazeb2.com/file/altstore/altstore.ipa
455872 Failed to remove downloaded .ipa.
459568 Failed to remove .ipa.

The string is clearly written in the wrong offset 439424 than 455808. Why is this? And how do I fix it?

Note: I did think the string maybe larger and so it might not write, and I tried self-hosting the binary in my local machine as a shorter URL:

http://192.168.0.108:4000/altstore.ipa

(Renamed the downloaded altstore-beta.ipa to altstore.ipa but even that didn't work and gave the same issue of writing to the wrong offset.

5
  • 2
    Which flavor of dd? With GNU dd (8.32) and busybox dd (1.31.1), the result is 455808 https://f000.backblazeb2.com/file/altstore/altstore-beta.ipa. It might still not work regardless since you usually cannot patch binaries shorter strings with longer ones, and you need to 0-terminate them. You could try an URL shortener and hope it follows redirects... Commented Nov 29, 2020 at 8:43
  • 1
    according to my strings man page, -o is equivalent to -t o I would omit this, though that does not appear to be the issue. The two locations are exactly 16k bytes apart ... which I suspect must be relevant. I suspect you need the -a option on strings.
    – David G.
    Commented Nov 29, 2020 at 8:43
  • Another way to patch strings in binaries is with sed. It finds the offset by itself. (Works best if old and new string are the same length, otherwise you have to reinsert \0 terminator) Commented Nov 29, 2020 at 8:48
  • I tried the same download and got different locations from strings. And while there are normally issues with enlarging the strings, you may be getting lucky here, as there is a block of NULs after the path. You might just try patching with a text editor, using a binary editing mode, an overstrike text replacement, and extreme care.
    – David G.
    Commented Nov 29, 2020 at 8:55
  • @frostschutz The one that ships by default in macOS. Not sure how to look up the version of dd here because when I run --version it gives dd: unknown operand --version Commented Nov 29, 2020 at 9:37

0

You must log in to answer this question.

Browse other questions tagged .